1.7 Corporate Hierarchies of Good Designers

A last topic Brooks mentions in his "No Silver Bullet" article as a method for controlling essential complexity is to create a corporate hierarchy of great software designers, giving them a large pool of junior designers from which they can groom their replacements. The analogy to management is provided in that senior managers sit at the top, grooming their replacements from a broad base of junior managers. This cuts to the heart of the "art versus science" argument among software developers. Is software development something we learn or is it a talent with which we are born? I refuse to get dragged into this argument, but I will draw a potential analogy. If someone put a gun to my head and told me I had to learn to play the piano in one year (and I play no musical instrument), I wouldn't be too worried. If my life depended on it, I have no doubt I can learn to play the piano. If the person then told me that in three years I had to be a great concert pianist, I'd be a dead man!

Regardless of whether great designers are born or built, I think there is a serious flaw in creating a hierarchy of great designers. It is the same flaw that we find in some of corporate management today. From what sources do new ideas generally come? New ideas are traditionally the product of grass-roots movements starting at the lowest levels. By creating hierarchies, we risk stagnation. As evidence of this, I found it both surprising and interesting that much of structured design and stepwise refinement started in academia and was forced on a fairly reluctant industry, while much of object-oriented programming was founded in industry and research laboratories and forced on a reluctant academia (with a healthy set of notable exceptions). I believe the reluctance to offer object-oriented programming to undergraduates in academia stemmed from a hierarchy of people who have preached the merits of action-oriented development. The object-oriented community did not help by saying, "We have been building software wrong for the last 30 years; here is object-oriented programming ”it is the right way to do it."

We are now entering an era where software development has become too complex for structured methodologies to handle. The future only promises additional complexity as hardware evolves at its exponential pace. The question is, can we produce a software development methodology that offers a chance to eliminate accidental complexity and, at least, control essential complexity? I believe that the object-oriented paradigm, with its decentralized control flow, bidirectionally related data and behavior, implicit case analysis (i.e., polymorphism), and information-hiding mechanisms, coupled with rapid prototyping and an iterative model of software development, offer the best chance for achieving this goal. The remainder of this text will discuss a myriad of issues about this achievement and how it can be improved and tracked.