Embedded Muse 149 Copyright 2007 TGG September 21, 2007

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Agile 2007
- More on Test Driven Development
- Multitasking
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

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: https://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.
www.garystringham.com/museoffer.shtml

*****************************************************************

Agile 2007

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.

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

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:

Decrease Improvement
in in
productivity quality
19 40
25-35 62
15 76
5 to 6 30
17 36
16 18
60 to 100 38 to 267
22 0
90 45
16 16

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.

Multitasking

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.

Jobs!

Joke for the Week