The “No Silver Bullet” Principle

by Krishna on December 25, 2006

I recently read one of the most significant papers regarding software development: No Silver Bullet: Essence and Accidents of Software Engineering by Frederick P. Brooks, Jr., the author of the classic “The Mythical Man-Month”. The article is very relevant even today.

In the short history of software development, there have been several new products or processes that promises to make software development easier — visual IDEs, agile programming, object-oriented programming, etc. There is no denying that every such development brings valuable improvements to development teams, reducing time and effort.

But the question remains: How much easier can it get? Are we nearing the point where there is no need of programmers? In fact, this is a pet topic of some technical journalists who try to meet their deadlines with articles like “Product ‘z’ Released: The End of Programming?”

The article by Brooks answers this question by differentiating between the “essential” and “accidental” difficulties of building software. Any non-trivial software has essential difficulties like complexity, pressure for constant change and conformity and relative lack of visualization. The difficulties encountered by poor programming tools and development software are accidental.

One accidental difficulty is created when the programming language does not reach the level of abstraction that the user (“programmer”) needs to express the solution. This is mitigated as higher-level languages are created — C, C++, Java, etc. Brooks points out at some level, the complexity of the language may create additional intellectual burden for the user. This is what happened with C++: When Java came out with LESS features (such as removing multiple inheritance and pointers), it became more popular.

The idea in the article is that even though we may use all the best tools possible, we still have to deal with the inherent complexity of the software itself. Consider any application: It has to deal with many different business rules. It has to accommodate the needs of different levels of users (beginner, intermediate and advanced). It has to consider different workflows and be able to act appropriately according to the current stage it is in. The number of combinations of stages, user actions and rules is quickly overwhelming.

For example, suppose you create a program that can never be beaten in tic-tac-toe. An accidental difficulty would not having a development tool that can easily create a GUI for user input. But once you obtain such a tool (say Visual Studio), that difficulty disappears. However you are still left with the challenge of programming and ensuring that the program works for all the 9! (or 362,880) combinations the game can be played. [It will actually be less than 9! because some games will end before all squares are filled in, but nevertheless you still have to take all possibilities into consideration and eliminate the necessary ones.]

A tic-tac-toe game is actually a very simple example. In a real-life program, there will be millions of possible stages that a program could be in. It is impossible to consider all of these possibilities or to test for them even using automation sometimes. Developers have to make decisions about the probability of use of features and focus on getting them right.

Much of the hype around all-knowing software has to do with the following types of situations:

  • Being able to create and maintain basic lists
  • Create web pages or other types of forms
  • Create visual reports and charts

Programs like Microsoft Excel (and Microsoft Access, to a lesser degree) have definitely put more power into the hands of people who have less programming experience. At the same time, you don’t see programmers out of their work. Having solved some of the basic problems (through better software), they have moved on to developing more complex and sophisticated software challenges.

Comments on this entry are closed.

Previous post:

Next post: