No Silver Bullet: Essence and Accidents of Software Engineering
No Silver Bullet: Essence and Accidents of Software Engineering
The article was written in 1987. Twenty five years in computer time is virtually equivalent to eternity. Even so, the article holds up rather well. Most of the problems Brooks describes with software complexity remain today. Brooks was perhaps a bit overly pessimistic; he considered the state of software engineering at the time to be in crisis. Using Brooks' analysis, modern, even more complex software should be at a developmental standstill. Yet the cycle of software development continues apace. Due to the Internet's tendency to quicken everything it touches, software development cycles even show a shortening tendency. The main problem as Brook rightly sees it is in specifying, designing and testing ‘conceptual construct’ underlying the system being developed and not in labor of representing it and testing the fidelity of the representation. The hard thing about building software he claims is deciding what one wants to say not saying it. In elaborating , he mention the super linear growth in the number of system growth in the number of system states, the difficulty of comprehending the conceptual construct and communicating it to others and what he believes to be it is, inherent un visualizable character. Among ‘non bullets’ he discusses are high level languages, object oriented programming, artificial intelligence and expert systems, automatic programming, graphical languages, program verifications, hardware improvements. In his introduction, Brook says that although he sees no startling breakthroughs in the next decade, “many encouraging innovations are underway” and eventually they will be exploited to “yield and order of magnitude improvements” However he claims that they deal only with representation issues which constantly the accidental part of problem. Imagine an article appearing then and claiming the essence of the problem to be deciding what ones wants to say, that is conceiving
The article was written in 1987. Twenty five years in computer time is virtually equivalent to eternity. Even so, the article holds up rather well. Most of the problems Brooks describes with software complexity remain today. Brooks was perhaps a bit overly pessimistic; he considered the state of software engineering at the time to be in crisis. Using Brooks' analysis, modern, even more complex software should be at a developmental standstill. Yet the cycle of software development continues apace. Due to the Internet's tendency to quicken everything it touches, software development cycles even show a shortening tendency. The main problem as Brook rightly sees it is in specifying, designing and testing ‘conceptual construct’ underlying the system being developed and not in labor of representing it and testing the fidelity of the representation. The hard thing about building software he claims is deciding what one wants to say not saying it. In elaborating , he mention the super linear growth in the number of system growth in the number of system states, the difficulty of comprehending the conceptual construct and communicating it to others and what he believes to be it is, inherent un visualizable character. Among ‘non bullets’ he discusses are high level languages, object oriented programming, artificial intelligence and expert systems, automatic programming, graphical languages, program verifications, hardware improvements. In his introduction, Brook says that although he sees no startling breakthroughs in the next decade, “many encouraging innovations are underway” and eventually they will be exploited to “yield and order of magnitude improvements” However he claims that they deal only with representation issues which constantly the accidental part of problem. Imagine an article appearing then and claiming the essence of the problem to be deciding what ones wants to say, that is conceiving