For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.
By Jack Ganssle
"It depends on what the meaning of the word 'is' is." -Bill Clinton
"It depends on what the meaning of the word `is' is when you say `it is done'" - Wise managers to innumerable engineering teams
"Where is it?" he asks. Mozart points to his head. "Here, it's up here," he explained. "Now it's all just scribbling. Scribbling and bibbling and bibbling and scribbling." Wolfgang Amadeus Mozart, from the movie "Amadeus."
The smartest and most productive developer that ever worked for me had his own definition of "it is done." Once he understood every nuance of the problem, once he'd structured the solution in his head, the code was "done." After that it was simply taking dictation. Like Mozart he composed the entire intricate structure of the code in his head, and after that merely transcribed his thoughts into the computer. Also like Mozart, or at least the Mozart we know from the wonderful movie "Amadeus," his transcription was nearly error-free.
But like the movie-Mozart who spent many long nights feverishly writing his scores while hiding from angry customers, that developer, too, always grossly underestimated the effort needed to go from a brain full of design to a working implementation.
Nothing is more infuriating to a manager than hearing that a system or component is "done," and then later finding out that "done" does not mean completely working and tested. A wise manager realizes "done" means different things to different developers, so develops a questioning strategy to elicit the system's true status.
"Done" is a particularly problematic concept with traditional software engineering approaches. In most of these the bulk of the testing, and certainly the integration phase, is deferred till late in the project. When management wants to lop off a few weeks from the schedule, the end-phase - the testing - gets whacked. So no one really knows if the system works correctly.
Every agile methodology, though, stresses testing uber alles. No change, no matter how small, has any significance till the test suite runs. Any change, no matter how big, is considered "safe" once the test suite validates it. "Done" means the code is written. <i>and tested</i>. That profoundly alters the landscape of software development. It holds every modification, or every function, method, subsystem or complete system to the highest of standards: it works. "Done" indeed means done, without any Clintonian obfuscation.
Unfortunately, the automatic testing required by agile methods is tough in the embedded world. A user might have to press buttons or observe a display. Systems that interact with the real world might actuate something, yet have no feedback enable an automatic check to insure the right thing happened. Some developers build test harnesses to simulate the I/O. Frameworks like Catsrunner (http://www.agilerules.com/projects/catsrunner/index.phtml) help. Some commercial companies like Virtutech (http://virtuatech.com/), offer solutions. But testing remains a thorny problem for firmware. I think the next great breakthrough in software engineering will be some product or approach that makes automated testing more tractable.
Then we'll know that done means done.