Embedded Muse 149 Copyright 2007 TGG September 21, 2007
You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
EDITOR: Jack Ganssle, firstname.lastname@example.org
- Editorís Notes
- Agile 2007
- More on Test Driven Development
- Joke for the Week
- About The Embedded Muse
Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that itís not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/classes.htm .
Are you in the Seattle or Minneapolis area? Iíll present the Better Firmware Faster class in Minneapolis December 5, and Seattle December 7. Registration and other info here: http://www.ganssle.com/classes.htm . Youíll earn 0.7 Continuing Education Units, learn a lot, and hopefully have a bit of fun, too.
Iím just back from the Embedded Systems Conference in Boston. The topic of code coverage came up in one class. Some standards, such as various levels of DO-178B, require it. Do you use code coverage tools like Bullseye or Semantic Designs? If so, are you pleased with the results? Drop me an email and Iíll share the results in a future Muse.
This issue of the Muse is sponsored by Gary Stringham:
Have you been stuck trying to integrate hardware and firmware?
Is your firmware tasked with fixing hardware defects?
Have you felt blind trying to see what your chip is doing?
Click here for your free copy of ten test and debug hooks that
reduce troubleshooting time and expense in your embedded system.
I attended the Agile 2007 conference in Washington DC last month. Itís a small but highly-focused convention that offered classes mostly targeted to PC/IT developers, though a few sessions were specifically aimed at the embedded crowd. One comment that resonated was this: Thereís no partial credit. Done means done. Done doesnít mean itís partly tested. It doesnít mean the documents arenít finished.
The best developer I ever had didnít get ďdone.Ē Heíd tell me the code was done when he had it all figured out in his mind. This person was so good that he was like Mozart taking nearly-perfect dictation once the music/code existed in his head. Though this was a thing of beauty to watch, the code wasnít done and served no useful purpose till it was compiled, linked, integrated and tested. Done. ďDone,Ē used improperly, is just another ugly four letter word.
I also enjoyed a series of talks about open office environments. The idea is to tear down walls to increase communication. Some of the presenters had removed all of the offices and cubicles, grouping everyone into one bull pen. Others created a mix of open spaces and cubes, sometimes with a few private areas available for use on an as-needed basis.
Great communication is indeed a hallmark of any sort of effective behavior, whether in marriage or the engineering lab. But privacy has its role, too. DeMarco and Lister showed long ago that interruptions are productivity killers. The human brain can juggle five to nine things at once. When youíve created that beautifully-intricate function in your head Ė when itís designed but not ďdoneĒ Ė and someone interrupts, wondering where the coffee filters are stored, the entire structure collapses. Youíve got to rebuild it at some cost in efficiency.
To my knowledge open office spaces havenít been studied very much. One experiment I monitored at a government agency saw a 70% productivity drop, though the spaces offered no private retreats for those doing complicated thinking.
Iím interested in any data or experiences people have had in open office spaces, and will pass along comments.
More on Test Driven Development
The May/June 2007 issue of IEEE Computer is devoted to TDD, and has a couple of worthwhile articles. One that scales directly to firmware developers describes using TDD to build a PID Controller.
Another, by Robert Martin of Object Mentor starts off: ďProfessional software developers ship clean, flexible code that works Ė on time. It seems to me that this statement is the minimum standard for professional behavior for software development. Yet, in my travels as a software consultant, Iíve met many software developers who donít set the bar this high and instead ship late, buggy, messy, and bloated code.Ē He then goes on to slightly contradict himself by saying that the developers *want* those qualities, but just canít believe these goals are achievable. That mirrors my experiences traveling around the firmware industry, though Iíd add the caveat that sometimes unmitigated pressures from on-high make developers despair.
The guest editors (Ron Jeffries and Grigori Melnik) include a table summarizing 19 experiments in using TDD. Four of those did not measure productivity effects. 11 had an increase in effort Ė a decrease in productivity Ė ranging from 5 to 100%. Sounds like a loser, except that quality often improved dramatically. Seven of the studies showed no quality effect, one resulted in worse code (note that case was one that didnít measure productivity), and 11 yielded quality gains ranging from 16 to an impressive 267%.
For the studies that measured both productivity and quality, the results were:
5 to 6 30
60 to 100 38 to 267
Sometimes studies cloud rather than clarify issues, but the overall picture, painted impressionistically by these widely-varying numbers, says that TDD users deliver later but with much better code. Why? One could speculate that they are delivering more code, embodied in a complete test suite.
No, by multitasking Iím not talking about implementing an RTOS. This is about juggling multiple activities more or less at the same time. You work on project A, move to B, then C, and back to A.
And give up huge amounts of productivity.
In "The New Brain: How the Modern Age Is Rewiring Your Mind," author and neurologist Richard Restak claims that on our brain works most efficiently when working on a single task for a sustained Ė not intermittent Ė period of time.
In Quality Software Management Gerald Weinberg claims that multitasking between three projects incurs a 40% context switching overhead. So in that 40 hour workweek, if switching frequently between three activities, youíre putting in 24 useful hours of work. To look at this another way, over 800 hours a year Ė 20 work weeks Ė go to context switching.
Sometimes I envy the younger generation as they somehow manage to juggle a half-dozen electronic connections at the same time. Their brains must be more attuned to simultaneously managing many activities, since for their entire lives theyíve been immersed in the electronic maelstrom.
Or maybe not. Research at the Institute for the Future of the Mind used groups of people between 18 and 21, and between 35 to 39, to study these effects. All were required to do a simple translation scheme. The younger folks were 10% more productive, when not interrupted. But a short IM, cell call, or text message eliminated the difference. The oldsters and young Ďuns did equally poorly.
Joke for the Week
Andy Kunz sent this link to a site that compares languages to cars. Itís pretty funny: http://www.cs.caltech.edu/~mvanier/hacking/rants/cars.html .