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

Stop Writing Big  Programs  37


                          Similarly, cut programs into smaller units. Since a large part of the
                     problem stems from dependencies (global variables, data passed between
                     functions, shared hardware, etc.), find a way to partition the program to
                     eliminate-or minimize-the  dependencies between units.
                          Traditional computer science would have us believe the solution is
                     top-down decomposition of the problem, perhaps then encapsulating each
                     element into an OOP object. In fact, “top-down design,” “structured pro-
                     gramming,” and “OOP’ are the holy words of the computer vocabulary;
                     like fairy dust, if we sprinkle enough of this magic on our software all of
                     the problems will disappear.
                          I think  this  model is one of  the most outrageous scams ever per-
                     petrated  on the embedded  community. Top-down  design and OOP are
                     wonderful concepts, but are nothing more than a subset of our arsenal of
                     tools.
                          I remember interviewing a new college graduate, a CS major. It was
                     eerie, really, rather like dealing with a programmed cult member unthink-
                     ingly chanting  the persuasion’s  mantra. In this case, though, it was the
                     tenets of structured programming mindlessly flowing from his lips.
                          It struck me that programming has evolved from a chaotic “make it
                     work no matter what” level of anarchy to a pseudo-science whose precepts
                     are practiced without question. Problem Analysis, Top-Down Decomposi-
                     tion, 00P-all  of these and more are the commandments of structured de-
                     sign, commandments we’re instructed to follow lest we suffer the pain of
                     failure.
                          Surely there’s  room  for iconoclastic  ideas. I fear we’ve  accepted
                     structured design, and all it implies, as a bedrock of our civilization, one
                     buried so deep we never dare to wonder if it’s only a part of the solution.
                          Top-down decomposition and OOP design are merely screwdrivers
                     or hammers in the toolbox of partitioning concepts.




                          Partitioning
                          Our goal in firmware design is to cheat the exponential in the CO-
                     COMO model, the exponential that also shows up in every empirical study
                     of software productivity. We need to use every conceivable technique to
                     flatten the curve, to move the M factor close to unity.
                          Top-down  decomposition  is  a  useful  weapon  in  cheating  the
                     COCOMO exponential, as is OOP design.  In  embedded  systems we
                     have  other  possibilities  denied  to  many  people  building  desktop ap-
                     plications.
   45   46   47   48   49   50   51   52   53   54   55