Twenty-one years have passed since Frederick P. Brooks, Jr.‘ seminal article “No Silver Bullet – essence and accidents of software engineering” was published. Today at OOPSLA, the author himself joined a panel discussion on questions like ‘Has there been a silver bullet’, ‘will we ever see a silver bullet’, and ‘how can we tackle the increasing complexity in computer systems’.
The panel took a most interesting turn during panelist introductions when Martin Fowler appeared as a werewolf (he actually put on a mask which he kept for the rest of the debate). The werewolf went on to argue that the field of software has not made many strides to kill him, due to things as waterfall (which dilutes people with the illusion of having control and being able to predict the future), the fact that people really don’t understand how difficult software programming is, lack of communication between business people and programmers, and that nobody actually does object orientation.
At this point it should be noted that a silver bullet is according to legend thought to have the ability to kill werewolves…
David Parnas, another panel member, suggested that we should focus on lead bullets instead of trying to reach the illusion of a silver bullet. A lead bullet being a tool or method to enable us to to things much better. He also made some of the funniest remarks (although the first prize in this category went to the werewolf), such as “people in the software business would sell wooden legs to snakes” (meaning that the marketing people are trying to sell non-existent silver bullets all the time). “Poor workmen blame their tools” was also a remark to be noted.
Looking back at the original paper, Linda Northrop underlined that the innovations we have seen has focused too much on accidents rather than the essence (of course referring to the “No Silver Bullet” paper). Fred Brooks went on to state that if you focus on the accidents you will never fix the real problem.
Dave Thomas stated that one of the problems is that we are creating to complex programs for relatively simple problems, and that the libraries we have today is too complex for most users. He underlined that the agile community does not have the problem for the problem with very large solutions, but the fact that agile has made the programmers think it is important to test, has to be good for something anyway! For large scale systems, he noted, we need more than agile, we need an engineering approach to the challenges we face.