Page 45 - The Art of Designing Embedded Systems

32 THE ART OF DESIGNING EMBEDDED SYSTEMS

much of this stems from a lousy job done in the first week of the project
when we didn’t carefully estimate its complexity.
It’s time to stop the madness!
We learn in school to practice top-down decomposition. Design the
system, break each block into smaller chunks, and iterate until no part of
the code is more than a page or two long. Then, and only then, can you un-
derstand its complexity. We generally then take a reasonable guess: “This
module will be 50 lines of code.” (Instead of lines of code, some compa-
nies use function points or other units of measure.)
Swell. Do this and you will still almost certainly fail.
Few developers seem to understand that knowing code size-even if
it were 100% accurate-is only half of the data absolutely required to pro-
duce any kind of schedule. It’s amazing that somehow we manage to solve
the equation

development time = (program size in Lines of Code)
x (time per Line of Code)

when time-per-Line-of-Code is totally unknown.
If you estimate modules in terms of lines of code (LOC), then you
must know-exactly-the cost per LOC. Ditto for function points or any
other unit of measure. Guesses are not useful.
When I sing this song to developers, the response is always, “Yeah,
sure, but I don’t have LOC data. . what do I do about the project I’m on
today?’ There’s only one answer: sorry, pal-you’re outta luck. IBM’s
LOC/month number is useless to you, as is one from the FAA, DOD, or
any other organization. In the commercial world we all hold our code to
different standards, which greatly skews productivity in any particular
measure.
You simply must measure how fast you generate embedded code,
every single day, for the rest of your life. It’s like being on a diet-even
when everything’s perfect, and you’ve shed those 20 extra pounds, you’ll
forever be monitoring your weight to stay in the desired range. Start col-
lecting the data today, do it forever, and over time you’ll find a model of
your productivity that will greatly improve your estimation accuracy.
Don’t do it, and every estimate you make will be, in effect, a lie-a wild,
meaningless guess.

Step 7: Consfanfly Study Software Engineering
The last step is the most important. Study constantly. In the 50 years
since ENIAC we’ve learned a lot about the right and wrong ways to build