More about the technology behind SCRAM:

According to 1800DUILAWS, “The SCRAM bracelet measures alcohol using the same fuel cell technology used by most portable breath testing devices. With this particular device, the fuel cell is manufactured by Draeger – (Dräger is an international leader in the fields of medical and safety technology. Founded in Lübeck in 1889, Dräger has grown into a worldwide, DAX-listed enterprise.  Drager Safety Diagnostics, Inc (a subsidiary of Drager) offers its customers complete hazard management solutions with a special focus on personal safety and protecting production facilities.  Ayoka was contracted by Drager Safety Diagnostics, Inc on behalf of the State of New Jersey, to develop an Oracle database and Java solution that integrated with Dräger’s alcohol breath analyzer, the only evidential breath tester on the market approved by a United States Supreme Court decision.) an Ayoka client. Once in place the device will monitor the wearer based on a schedule set by the monitoring agency. Then, at a predetermined time, the bracelet communicates with a home-placed modem via a 900 MHz radio signal. The readings are sent to a remote computer that acts as a central clearing house of data where it is monitored and interpreted. The data for a specific offender is then available to the home state’s monitoring agency through a secure Internet Web site.”

So what puts a project at risk, and how do we plan to deal with these risks when they occur?
Steve McConnell, the patron saint of practical software development practices, eloquently identifies some of the common problems that bring software projects to ruin.

TYPES OF RISKS

CAN-DO ATTITUDES

As McConnell points out, in software development, optimism can be deadly. An optimistic, can-do attitude often leads to the creation of impossible schedules that puts projects at risk of failure. In order to mitigate this risk, it’s imperative that developers and managers alike adopt a healthy, pessimistic attitude. Plan for the worst and aim for the best. Don’t ever rely on luck or good fortunes to see your team through to the end. Optimism and hope is not a replacement for solid planning and risk management.

FUZZY REQUIREMENTS

Software development companies often bow to the pressures of their clients and rush through the requirements analysis and design phases. This is always a mistake. Many studies show that the cost of repairing requirements mistakes outweighs the cost of repairing implementation mistakes by several orders of magnitude. Spend the time to get requirements right before starting even the design phase of the software. In the long run, it will save your company a bundle. And don’t take just my (or McConnell’s) word for it – there is plenty of plenty peer-reviewed research demonstrating the validity of these claims.

GOLD-PLATING

Gold plating occurs when developers and managers add features to software to make it “better.” This often occurs past the requirements and design phase, where the implementation of a new feature is far more costly than it would have been had it been planned out in the initial phases of the software’s development. Customers, developers, and managers alike are all responsible for this. Each stakeholder should take different steps to manage this risk:

• Developers: it is the developer’s job to explain to managers what is possible and what isn’t. As most developers know, what seems like a simple change on the surface (adding a button that performs some nifty function) sometimes requires substantial modifications to a whole subsystem. Accurately estimate the difficulty of any proposed change and make sure that your managers are fully aware of what functionality may be placed at risk by the change.
• Managers: it is your job to determine how important a change is to the software’s “mission” since they are the ones most in touch with the customer’s point of view. If the change is a convenience change, leave it out. It’s often tempting to add nifty little features toward the end of a project, but the road to hell is paved with good intentions. On the other hand, if the change is absolutely vital to the mission’s success, explain this to the developers so that they don’t take a morale hit from going back and rewriting old code.
• Customers: customers are an integral part of the development team and the whole reason behind the team’s existence. It is imperative for project success that the developers know precisely what requirements they need to fulfill. Customers should review requirements documents carefully before signing off on them and not hesitate to point out any mistakes. Remember that misunderstood requirements cost tens to hundreds of times more than implementation mistakes.

THE MYTHICAL MAN-MONTH

Project managers sometimes fall into the trap of viewing software development as an assembly line process. It leads to the idea that if a project is behind schedule, adding more developers to the team will automatically bring the company closer to the goal.

This sort of thinking is horribly and fundamentally wrong.

McConnell cites a number of studies demonstrating that not only does adding developers at mid-to-late phase during a project not increase productivity, it actually detracts from it. The reason for this is simple: in any complex project, it takes time to bring a new developer up to speed on both the domain knowledge and the project architecture. Existing developers on the team must then spend some of their time fixing the inevitable mistakes made by the new team member and attempting to train the new developer.

So how do we manage this? The answer is fairly simple. Build your team immediately and then involve them at every phase of the project. A developer who was involved in the requirements analysis and the design phase will be more productive than a developer who is starting out with little to no knowledge of the project’s intricacies. Involvement is the key.

SILVER-BULLET SYNDROME

This risk tends to apply more to developers than to project managers. We’re a technology-loving bunch, on the whole, and so when a new framework comes out that promises to make our lives easier, we’re almost instantly ready to jump onto the bandwagon. So optimistic are we that we’ll gain productivity from the new technology that we revise our software cost estimates to reflect the expected productivity gains.

This is dangerous.

Although new technology often does increase productivity, it is not possible to predict the sorts of things that can go wrong with a new technology. It is also important to factor in time for training on the new technology, a facet of a developer’s job which is often underestimated.

While nothing is intrinsically wrong with trying new technology, it is important to be conservative with cost estimates when walking on uncertain ground. This ties in to the risk of optimistic thinking, outlined above.

RISK MANAGEMENT

There are many other common types of risk that fall well beyond the scope of a blog post. The important thing for developers and managers to do is to sit down with one another and draft a risk management plan. The trite aphorism is telling: if you fail to plan, plan to fail. Determine at the beginning of a project what might go wrong and how best to deal with the situation should it occur.

Following this strategy will result in better software for customers, lower costs of development, and fewer grumpy developers.

Abbreviations

As many of us know, we computer geeks love abbreviations. Whether it be the various components of a computer (RAM, CPU, PSU ) to the documents that we write/read (SRD, SOW, DDD), and then there are the various software technologies we use (RIA, AJAX, CSS). Because the default Wordpress search only performs a simple search for the presence of the search terms, abbreviations can return all sorts of crazy but logical results. Take for example, the search term “RIA.” Using the default Wordpress plugin, it returned various articles about indust-ria-l devices.

Relevance

The other major issue was that, thanks to Google, users have become spoiled with this whole concept of relevance. People expect the top results to be the pages that are most likely related to the topic they’ve searched for. Determining relevance varies from search engine to search engine, but mostly it is determined by the number of times a search term is used, where it’s used, and the words surrounding it. Making a site more relevant for certain keywords is such a big deal that it has spawned a brand new abbreviation: SEO. Having a relevant search capability for your own site tends to be a big deal since it makes life easier for your readers/clients.

To resolve these search issues, I ended up trying numerous plugins. This approach led me to the following conclusion: plugins fall into one of two categories. There are the “search everything from author to page/blog title” plugins and then there are the “search by relevance, but only for blogs or pages and maybe, if we feel like it, their titles” plugins. After I started paying attention to the timestamps on the various plugin pages, I reached yet another conclusion: these plugins are extremely short lived. Most of them receive up to a year’s worth of development, and then the developer’s disappear off the face of the Earth.

Ultimately, Google came to the rescue with Google Site Search, a special embeddable code snippet that allows you to use Google to search only your website. Unfortunately, this bears some consequences of its own. Unless you like various text ads all over your results, you have to subscribe to the service with fees based on the page count of your site. It’s a bit steep at $100-$250 per year for smaller sites and a lot more for bigger sites. Also, the results are a little painful to customize without doing some good ‘ol XML API interfacing.

In conclusion, Wordpress searching sucks. The Google site search makes it sort of better, but I really wish Wordpress would devote some of their resources to improving their default search system. The pain I suffered trying to improve it via plugins and Google has certainly made me reluctant to use Wordpress again.

Below are some of the features that I’m looking forward to using.

1. The border-radius property – Allows you to create rounded corners for box items. What a time saver this will be! No need for images or fancy techniques to get the rounded corners you want. Supports the capability to specify a radius for one or more corners. Currently supported in Firefox and Safari 3.
2. Multiple Backgrounds for a single element – Ever wanted to apply more than one background to a single element? Well now you can! For the background property, simply separate backgrounds by commas. At the time of this post, only supported by Konquerer and Webkit.
3. The box-shadow property – One of the features I’m most looking forward to. Allows you to apply a shadow for box items even with rounded corners. Again no images required! Currently supported in Firefox 3.1 and Sarfari 3+.
4. The border-image property – Allows you to specify an image for a border instead of a normal border and can be applied for one more sides. Currently supported in Safari and Firefox.

Q: How many programmers does it take to change a light bulb?
A: None – It’s a hardware problem

“Knock, knock.”
“Who’s there?”
very long pause….
“Java.”

Q. Why do programmers always get Christmas and Halloween mixed up?
A. Because DEC 25 = OCT 31

Q. How do you keep a programmer in the shower all day?
A. Give him a bottle of shampoo which says “lather, rinse, repeat.”

Q. “Have you heard about the object-oriennted way to become wealthy?”
- “No…”
- “Inheritance.”

Two bytes meet. The first byte asks, “Are you ill?”
The second byte replies, “No, just feeling a bit off.”

Eight bytes walk into a bar. The bartender asks, “Can I get you anything?”
“Yeah,” reply the bytes. “Make us a double.”

Programming is like sex:
One mistake and you have to support it for the rest of your life.

From my exploits in the computer world, I have found that a “geek” tends to have an interest in subjects of academic or technical importance. A “nerd’s” interest seems to be more trivial, like knowing every line in every “Star Wars” movie. That being said, I believe a geek tends to have a higher intellect than a nerd and more specialized skills. I might go as far to say that a nerd is a geek, but without skills.

Geeks usually choose their concentration over conformity while a nerd chooses his obsession over conformity. A dork is described in the dictionary as someone that is stupid or ridiculous. In high school, if someone called you a dork, you need to check yourself and possibly buy some deodorant. However, if they call you a geek or a nerd, more than likely one day they will be working for you. The truth of the matter is that I consider myself all three and I am proud of it!

Comments are immensely beneficial to anyone that is going to be dealing with your code, including yourself. There are many places where comments are helpful, including those describing a method, those describing class properties, those describing classes, and those describing the purpose of a block of code. Of those listed, I feel commenting a method is the most beneficial. Object-oriented programming (OOP) naturally tends to have many method calls across many different classes, and being able to find your way around and determine the expected input and output of a method, but also the purpose of a method can be a lifesaver. Even one brief sentence can help someone out that would otherwise have absolutely no clue what this method you wrote is for. Not only do comments help you later on down the road, after you’ve written the code and possibly forgot what a method was for, but it has the immediate benefit of making you think, “what is the purpose of this method?” If you comment methods before you write the implementation, you have a “definition” of the method, and when implementing your method, you’ll be able to tell if the purpose of the method is becoming fuzzy or if the code you’re writing is spot on with your original intentions of writing the method.

It is also important to note that most modern IDE’s have the ability to parse through comment blocks above methods and the better the comments, the better smarter the code completion will be. For the purists, some IDE’s allow you to throw errors at compile-time if a method is not commented, a feature that I sometimes find a burden, but more often than not has led to me writing better code than I would have otherwise.

Some feel that well written code doesn’t need comments, and some (I don’t get this logic) feel lots of comments are bad because it demonstrates that the code is not self-descriptive. This is just plain wrong, well-documented code rarely, if ever, means code is sub-par. In fact, I would go as far as to say the opposite is true, if I see good comments, I get that piece of mind that the author of the code knew his intentions well and planned out the code well enough to be able to define a purpose for each method, each class is carefully targeted and named for a specific purpose. If I saw a library with 500,000 lines of code, I would honestly be pretty scared of the stability and robustness of such a library.

Lastly, if you don’t want to take my word for it, look at any open source code library. I’d be willing to bet comments are poured liberally throughout the entire library. It’s not uncommon for the comment of a method to be longer than the implementation of the method. There is such thing as too many comments, but too much is better than not enough.

So, in conclusion, don’t be afraid to use comments, they’re your friend.