Page 44 - The Art of Designing Embedded Systems
P. 44

Disciplined Development  3
                                                                                    1
                          Step 6: Measure Your Code Production Rates

                          Schedules collapse for a lot of reasons. In the 50 years people have
                     been programming  electronic computers,  we’ve learned one fact above
                     all: without a clear project specification, any schedule estimate is nothing
                     more than a stab in the dark. Yet every day dozens of projects start with lit-
                     tle more definition than, “Well, build a new instrument kind of like the last
                     one, with more features, cheaper, and smaller.” Any estimate made to a
                     vague spec is totally without value.
                         The corollary is that given the clear spec, we need time-sometimes
                     lors of time-to   develop an accurate schedule. It ain’t easy to translate a
                     spec into a design, and then to realistically size the project. You simply
                     cannot do justice to an estimate in two days, yet that’s often all we get.
                          Further, managers must accept schedule estimates made by their peo-
                     ple. Sure, there’s plenty of room for negotiation: reduce features, add re-
                     sources, or permit more bugs (gasp!). Yet most developers tell me their
                     schedule estimates are capriciously changed by management to reflect a
                     desired end date, with no corresponding adjustments made to the project’s
                     scope.
                          The result is almost comical to watch, in a perverse way. Developers
                     drown themselves in project management software, mousing milestone tri-
                     angles back and forth to meet an arbitrary date cast in stone by manage-
                     ment. The final printout may look encouraging, but generally gets the total
                     lack of respect  it deserves  from the people doing the actual  work. The
                     schedule is then nothing more than dishonesty codified as policy.
                          There’s an insidious sort of dishonest estimation too many of us en-
                     gage in. It’s easy to blame the boss for schedule debacles, yet often we bear
                     plenty of responsibility. We get lazy, and we don’t invest the same amount
                     of thought, time, and energy into scheduling that we give to debugging.
                     “Yeah, that section’s kind of like something I did once before” is, at best,
                     just a start of estimation. You cannot derive time, cost, or size from such a
                     vague statement . . . yet too many of us do. “Gee, that looks pretty easy-
                     say a week” is a variant on this theme.
                          Doing less than a thoughtful, thorough job of estimation is a form of
                     self-deceit that rapidly turns into an institutionalized lie. “We’ll ship De-
                     cember l ,” we chant, while the estimators know just how flimsy the frame-
                     work of that belief is. Marketing prepares glossy brochures, technical pubs
                     writes the manual, and production orders parts. December  1 rolls around,
                     and, surprise! January, February, and March go by in a blur. Eventually
                     the product goes out the door, leaving everyone exhausted and angry. Too
   39   40   41   42   43   44   45   46   47   48   49