Embedded software devt: The disciplined way (Part 2)(2)

As time goes on, though, the tool vendors obsolete their compilers, linkers, debuggers, and the like. When you suddenly have to change a product originally built with version 2.0 of the compiler—and now only version 5.3 is available—what are you going to do?

The new version brings new risks and dangers. At the very least it will inflict your product with a host of unknowns. Are there new bugs? A new code generator means the real-time performance of the product will surely differ. Perhaps the compiled code is bigger, and no longer fits in ROM.

It's better to simply use the original compiler and linker throughout the product's entire lifecycle, so preserve the tools . At the end of a project check all of the tools into the VCS. It's cheap insurance.

When I suggested this to a group of engineers at a disk drive company, they cheered! Now that big drives cost virtually nothing there's no reason not to go heavy on the mass storage and save everything.

A lot of vendors provide VCS. But today the most popular is the open source Subversion. Another open source product, Trac, gives Subversion a Wiki front end with a better user interface.

Step 2: Institute a firmware standards manual.
You can't write good software without a consistent set of code guidelines. Yet, the vast majority of companies has no standards, no written and enforced baseline rules. A commonly cited reason is the lack of such standards in the public domain. (Appendix A, in "The Art of Designing Embedded Systems, Second Edition" includes one possible standard proposal.)

Step 3: Use code inspections.
Testing is important, but used alone will lead to products infested with bugs. Testing usually exercises about half the code. The solution is a disciplined program of code inspections.

Everyone loves open source software, mostly because of the low bug rate. Remember the open source mantra: "with enough eyes all bugs are shallow."

That's what inspections are all about.

Step 4: Create a quiet work environment.
For my money the most important work on software productivity in the last 20 years is DeMarco and Lister 's Peopleware (1987, Dorset House Publishing, NY). Read this slender volume, then read it again, and then get your boss to read it.

For a decade the authors conducted coding wars at a number of different companies, pitting teams against each other on a standard set of software problems. The results showed that, using any measure of performance (speed, defects, etc.), the average of those in the 1st quartile outperformed the average in the 4th quartile by a factor of 2.6.

Surprisingly, none of the factors you'd expect to matter correlated to the best and worst performers. Even experience mattered little, as long as the programmers had been working for at least 6 months.

They did find a very strong correlation between the office environment and team performance. Needless interruptions yielded poor performance. The best teams had private (read "quiet" ) offices and phones with "off" switches. Their study suggests that quiet time saves vast amounts of money.

Think about this. The almost minor tweak of getting some quiet time can, according to their data, multiply your productivity by 260%! That's an astonishing result. For the same salary your boss pays you now, he'd get almost three of you.

The winners—those performing almost three times as well as the losers—had the environmental factors:

Too many of us work in a sea of cubicles, despite the clear data showing how ineffective they are. It's bad enough that there's no door and no privacy. Worse is when we're subjected to the phone calls of all of our neighbors.

We hear the whispered agony as the poor sod in the cube next door wrestles with divorce. We try to focus on our work but being human, the pathos of the drama grabs our attention till we're straining to hear the latest development. Is this an efficient use of an expensive person's time?

Various studies show that after an interruption it takes, on average, around 15 minutes to resume a "state of flow"—where you're once again deeply immersed in the problem at hand. Thus, if you are interrupted by colleagues or the phone three or four times an hour, you cannot get any creative work done! This implies that it's impossible to do support and development concurrently.