Elvis Montero

Design as the silver bullet

Frederick P. Brooks Jr’s “No Silver Bullet” is a famous, widely discussed paper in software engineering fora around the world. One can clearly see why within seconds of reading a few lines:

Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.

The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet–something to make software costs drop as rapidly as computer hardware costs do.

Mr. Brook wrote this in 1986. Today, 22 years later, we are still not even close to finding the sought-after solution that’s going to make every software development project end on time and within budget. While Mr. Brooks’ “No Silver Bullet” focuses mostly on the difficulty of development tasks per se, the elements he described can easily be interpolated inside boundaries of design methodologies. That is, we can take Mr. Brooks’ remarks and see how they relate to design concepts. As any part of the software development life cycle, good designs are hard (if not harder) for several reasons.

Firstly, there is complexity (the initial topic in “No Silver Bullet”). How can one successfully break down an intricate system and explain its many elements easily? One’s design should be clearly constructed so that others can pick it up effortlessly. Ideally, smooth implementation and maintenance would naturally ensue. Of course, this is also a major problem when developing (i.e. coding) the system/application. Unsurprisingly, one of the most lauded techniques in the software engineering realm is divide and conquer — smaller, distinguishable problems are easier to attack and solve!

Secondly, Brooks goes on to talk about the power of new generation tools and programming languages. Design methodologies constantly use avant-garde, ever-changing modeling languages (e.g. UML). In the same vein, coding tasks are more manageable nowadays because of better programming languages and IDEs. However, complexity has not decreased an iota. On the contrary, it continually increases as more and more components are added to the system because of perennial new business needs.  That is why, despite impressive advantages in the aforementioned areas, design remains a tough chore. If software is hard, conceiving good designs is tantalizingly difficult!

Lastly, and most importantly, the mention of great designers cannot be eluded. Brooks emphasizes the importance of topnotch, high caliber engineers and their role within the software development process. Methodologies abound. Design artifacts and tools proliferate. However, these tools alone do not prelude good, easy to understand designs. The quality of the individuals comprising your development team is what ultimately determines success (or lack of thereof). A good design is only as good as its designer, no matter if the model is created by a single individual or a group. Software development in general (design, coding and every other related activity) is tremendously complicated. It requires huge amount of orchestrated efforts and individuals working in tandem. Hence, qualified and prepared individuals are of paramount importance for a prosperous software development.

If we are to find the magical panacea that’s going to remedy the status quo, whatever it may be, software design will most likely be a part of it. I personally think this is the fundamental silver bullet.