No Silver Bullet for Software - Is that Still True?

It was in the year 1987 when Frederick Brooks wrote his paper "No Silver Bullet: Essence and Accidents of Software Engineering" [1]. In this paper Brooks shared with the software development industry his view of the issues and challenges related to software development. Brooks stated that "Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any", Brooks also stated that the difficulties of software are broken down into two types, the first "essence" are difficulties inherent in the nature of software such as complexity, conformity, changeability and invisibility; and the second "accidents" are difficulties that today attend its production but are not inherent. Furthermore Brooks believed that "the hard part of building software is the specification, design and testing of this conceptual construct (referring to software), and not the labor of representing it and testing the fidelity of the representation".

Are Brooks' thoughts in 1987 still valid and true? This is what this write-up is trying to explore. While I agree with many of the points that Brooks' shares in his paper, I have a different opinion on some of the assumptions he made.

1. Brooks' sees that the issue with software development is not that it is too slow, but rather that hardware progress is too fast. I do not think we can generalize this statement, as a matter of fact a higher performing hardware will be more capable of running an older software much easier and with higher performance than an older hardware technology. We should expect that running Windows 95 on a Pentium 4 processor with 2GB of RAM will be much more efficient and effective than running it on a Pentium I processor with 64MB of RAM. It is true that Windows 95 will not be able to leverage all the benefits of the improved hardware, and to modify it to be able to do so will take probably more time than to move from a Pentium I processor development to a Pentium 4 processor development, this will impact the quality of the modified Windows 95 software, but not the original Windows 95. Taking into consideration the principle of system dynamics that a system's structure - and not the environment in which it is in - dictates its behavior [z2], the real issue lies neither in the slowness of software development nor the higher pace of hardware development, but rather in the structure and architecture of the developed software. It is developed in a way that allows fast, modular and low-error development, the newer release will be out on the market quicker and more will be more reliable. I see the main issue here is not that hardware development is orders of magnitude faster than software which is true, but rather that processes and methods used for software development are not mature and solid enough as those used in hardware development projects.

2. Brooks also mentions that computers have very large number of states and that this makes conceiving, describing and testing computers hard. This is another example of where a well-defined scalable process for state verification and behavior checking at these different states would solve the issue. Having many states does not add complexity, it only adds time demands and repetitive testing under different states, a task that should be easily achieved by a machine or computer. Brooks mixed between complexity and complication, software state definition might be time-consuming, complicated and repetitive, however the behavior of the application should be easily understood in a state given the various inputs and constraints. I do agree with Brooks that a larger number of elements in a software application will lead to a large level of interaction and that the results will most probably not be linear, and we can agree that the relationship between the whole and the elements is not linear and could very well be complicated as well as complex.

3. Since Brooks assumed that software applications are complex he assumed that communications among team members, program states, functions and structure are all complex. As mentioned earlier I believe they are not complex but rather complicated. If we use a part-to-whole, or bottom-up approach in architectural design we should be able to understand the program state, functions and capabilities at a lower level and as we add more capabilities we should map back to the original needs and be able to determine what the overall system would look like, and how it will behave, this might be a complicated process, but is should not be complex. If it were complex, that mans that somewhere in our design and development processes we lost track of what we are building and how it will behave, this requires a pause and revisit of the methods utilized, just like any other engineering discipline will do, to continue the engineering activity not fully aware of what has been achieved and how it maps to the stake-holder needs is poor and foolish engineering practice and is not an attribute of the engineering artifact being developed. To make an analogy a civil engineer designing a concrete mix for a skyscraper should know what the characteristics and behavior of the mix is expected to be, if there is a behavior that is unknown to the engineer in a particular state, say for example, at temperatures above 105F, proper engineering sense calls to pause, and do some analysis to find if the mix is still valid, or a redesign is needed, this same concept should apply to software development.If we are to assume that software implementation is complex, then yes, it will lead to difficulty of communication among team members, this is due to the fact a complex behavior means that the behavior of the software as a whole is not understood analyzing the parts of the software and hence team leads will not be sure which team members of the implementation to include in a communication. This difficulty of communication depends on several key factors, the number of team members, the tools, processes, standards and methods used for communication. Communication difficulty is common across any project team with large number of participants or on a project with poor communication planning.The difficulty mentioned in enumerating all the possible states of a program is also another weak point. With advanced tools and databases we can analyze the program behavior and document these findings along with state information in a database, which will make the management and retrieval of state information much more efficient and easier. Brooks has not illustrated how does complexity of function increase the difficulty in invoking function. Invoking function is dependent on user interfaces and program structure, and hence we can not assume that a more complex function will lead to a difficult access of such function. Today with the presence of patterns and contained components we feel that this becomes less of an issue from the days of Brooks.

4. Changeability is common in all technology areas today, rate of changes in non-IT technology areas might be less, but still high compared to other industries and segments. The issues of changeability is not a SW inherent problem, but rather a management issue. Brooks states in his paper that “SW can be changed more easily”. This is not true, what is true is the perception that SW changes can be easily implemented. Because SW is intangible and no fixed tangible assets are easily identified, managers and clients tend to not realize that SW just like any other area of technology requires a careful change management process. An airplane with 30 million parts on it could be much more complex when it comes to making changes. However because of all the steps that must be performed to perform the change; ranging from prerequistes for safety, reliability, regulation conformance and much more the cost of change is high and can not be negotiated. In the case of SW, a different peception is applied where we can do an easy change without impacting too many other areas, this claim is simply not true and could lead to the same disastrous effects of changes on an airplane, air traffic controller system, subway control system or stock exchange.

5. The argument that SW is invisible and “unvisualizable” by Brooks is not a strong one. Various methods of scenario representation, data flow, dependency patterns, time dependence could be implemented to improve the understanding and visualization of a software application process. What should be visualized is a business process, not the SW application, the SW application should be represented in a logical form as a tangible product comprised of smaller logical components. there are plenty of innovative methods of representing business processes and information thanks to the world of frameworks !

[1] F. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering", Computer, Vol. 20, No. 4 (April 1987) pp.10-19.

[2] J. Sterman, "Business Dynamics: Systems Thinking and Modeling for a Complex World", Irwin McGraw-Hill, 2000, pp. 28.