Gregory M. KapfhammerAssociate Professor of Computer Sciencehttp://www.cs.allegheny.edu/~gkapfham/ |
No Silver Bullet-Essence and Accident in Software Engineering
- Identify and explain the central hypothesis of this article about software engineering. Do you agree or disagree with Brooks' conception of software engineering?
Brooks feels that the "hard part of building software [is] the specification, design and testing of [the] conceptual construct, not the labor of representing it and testing the fidelity of the representation." He also beleives that because of this that there is no "silver bullet" that will be able to revolutionalize the software engineering field and cut the time it takes to develop a piece of software by an order of magnitude.
While I do agree that there is probably no silver bullet that will cure all of the problems of software engineering I don't think that this is as large of a problem as Brooks makes it out to be. A decrease of .5 or even .25 of the time it takes to create a software project is still a notable achievement in efficency. Brooks seems to feel that because the field of hardware design experianced on order of magnitude increase with the development of its silver bullet, VLSI, that software engineering should be able to find its own magical cure. I disagree. The design of software and hardware share very little in common. Even if we look at a field that is more similiar to hardware design, like the design of automobiles, we do not see a silver bullet. If automotive engineers were able to increase the efficiency of thier cars by an order of magnitute, increasing mpg from 20 to 200 or dropping the price from $20000 to $200 the world would rejoice, but as it is now we are happy with fractional increases in efficiency. If there's no chance for a silver bullet why dwell on it? Take the small advances and increases as you can find them. You may never reach on order of magnitude improvement but you may get close.
Jim Clause
I remember reading an anecdotal article in a popular software magazine that tried to extend your analogy that compares software and cars. They thought that if cars ran like software runs today, we would be willing to accept cars that "needed to be rebooted" or periodically "re-installed." Several prominent researchers and practioners in the realm of software have argued for good enough software; is this was you are arguing for? Do you think that it is possible for a small increase in productivity to result from the study of potential silver bullets? Greg
Brooks' ideas on the process of Software Design consists of two parts. First, determining the specifications of a problem to be solved and the formation of an abstract concept to meet these specifications. Secondly, the details that implement this concept. His hypothesis is that in order to improve the process of Software Design a better method of concept formation is needed, and that improving the way in which the details are implemented will not result in a significant gain ("in productivity, in reliability, in simplicity").
I both agree and disagree with Brooks. He is right, if easier methods of determining a problem's specifications and of abstracting a concept, to solve that problem, from those specifications were found the process of Software Design would improve by a considerable amount. He is wrong though when he claims that further considerable improvements cannot be had by making the details of a concept easier to implement. Changing the way designers determine specifications and concepts would probably result in greater gains than removing difficulties in implementation but there are still considerable gains to be had in both ventures.
Dan Fiedler
Can you give an example of a mechanism that would make it easier to translate a specification into an actual working program? What leads you to believe that improvements can be made in this area? What steps would you take to empirically evaluate your claim (and, thus, Brooks' claim as well)? If changing the way that we conceptually break down and desecribe software could stand to provid a bigger "bang for our buck", should we focus research efforst here? Greg
Brooks hypothesis is that unless the accidental tasks are nearly the whole project, cutting the amount of time invloved in handeling these taks will have little effect on the outcome of productivity for the entire project. He basicly assert that the essential tasks are where time can be saved, and that this is where the "Silver Bullet" would need to be found. Further more he asserts that there is no "Silver Bullet" and does not believe one will be able to be found as the hardware field did.
As did Dan I both agree and disagree with this idea. Brooks coments on both AI, and a Program that can solve Programs as ideas as a solution to this problem, however he shoots these ideas down. Saying that AI is just making a program "solve" a problem, then once it is solved it is no longer AI, and that a program to generate programs is just a mystical idea that can never really exist. Though at this current time I agree with his arguments, I am unwilling to say that in the future these are not going to be the "Silver Bullets" of the software design field. If 50 years ago someone would have stated the capabilities of the silcon chips of today, they would have recieved a similar reaction to what Brooks is saying about the concepts that exist in the software side. I guess only the future will tell.
Brandon Taylor
What makes you feel confident that AI will be able to provide us with practical tools and technologies that will enable automatic program construction? Is this simply because you are optimistic? What is your definition of the term "AI"? What kinds of AI techniques might be needed to make automatic program generation a reality? Greg
Brooks' central hypothesis is that there is no one thing that will increase software productivity by an order of magnitude. Throughout the paper he makes the distinction that the process of creating software is broken up into the essentials (the design/planning/specification part) and the accidentals (the details that don't necessarily have to be thought about until the time comes). He points out that several improvements have been made to the accidental side of the process but to achieve a true order of magnitude increase in software productivity, improvements have to made to the essential side.
I do agree with Brooks' "No Silver Bullet" concept, and those essentials present problems that have proven very abstract and difficult to "solve" (for lack of a better word). One of the accidentals that Brooks did downplay, though, that should be given more credit is that of Time Sharing. Invaluable, I feel, is the ability to compile programs in the span of seconds to minutes while sitting at the console. I don't think our generation can necessarily appreciate the amount of time we spend waiting for results versus the time spent by past programmers waiting for results (some of this can be attibuted to the increase in hardware capabilities, but the majority lies in the creation of software compilers).
Matt DeNapoli
I do think that fast compilers and hardware play a big role in my ability to develop software. For example, I like to use a development machine that can quickly build and test my system. Otherwise, I might have an idea that I would like to try out and then forget it by the time that compilation is done (if it took hours to compile something). Also, it is quite nice if my complete unit test suite can run in a matter of a few minutes. But, is there s such thing as "too fast"? Do you ever need time to just pause and reflect about your software design? Can really fast computers transform us into impetuous software engineers? Greg
- Brooks proposes certain classical problems that are normally associated with developing software products. What are these problems? Do you think that there are other problems that Brooks did not enumerate?
The classical problems that Brooks states are:
- Complexity: As software projects increase in size the become more and more difficult to understand. A small mountain has the same basic shape as a large mountain, a triangle, and a small tree has the same basic shape as a large tree. But a large software program looks nothing like a small software program.
- Conformity: Conformity consists of things that make a program look uniform. Variable naming conventions, commenting styles, indenting styles, and documentation styles. This can easily be achieved with a small group of developers who are able to spend time and decide before hand on these conventions. But as the size of software projects increase that small group of devlopers can no longer complete the program in a feasible amount of time. Other developers are brought in with different developement styles and the project begins to lose conformity with each additional developer.
- Changeability: Good software lives beyond the original system that it was created on. Because of this it become necessary to update the software even if the goals of the software do not change. Very rarely can you have the original developer return to the project to update it. This intruduces problems with conformity into the software which makes it harder to use the next time it needs to be updated.
- Invisibility: Invisibility is closly related to complexity. A small non-complex program can be visualized easily but as a program grows in size and complexity it become more and more difficult to represent it in a visual way. This forces developers to create new ways of describing what they are creating and how other software should interact with it. Showing someone several pictures of a blender is much easier than trying to describe it in a language or document.
You brought up an interesting point when it comes to adding people to a software project. Brooks happened to have some feelings about this issue. In your own experience, does it make sense to add more staff to a late software project? What if a software system could be visualized in an appropriate fashion, would you still consider it to be invisible? What if a software visualization was proposed that required many different, separate visualizations? Would this make software less invisible? Greg
Brooks' classical problems:
- Complexity: Software is an entity consisting of many, many different states. It is difficult to construct a model of a piece of software because many of its different states are required to define it. Complexity leads to several difficulties: in communication between team members, enumeration and understanding of a program's states, usage of a program's functions, in extending program's uses, and in visualizing all states of a program.
- Conformity: Brooke claims that conformity is "the arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform." Brooks complains that a designer's interface must look and function like other already existing interfaces.
- Changeability: Good software is pushed to its limits by users who like its primary uses and pressure developers to extend the uses on the edge of the software's abilities. Software also lasts longer than the machines it is intended for, forcing software to be updated for newer machines if it to be used. These two pressures influence software developers to design their programs to be easily changed in the future.
- Invisibility: Software exists outside the realm of immediate perception, it has very little substance in the concrete. Software is also complex. Because of these two factors, it is hard to model a piece of software, it is difficult to visualize a program. Without a model, one suffers from all the difficulties of complexity (communication, understanding, usage...)
You seem to be suggesting that we can hurdle the problem of conformity my simply building better interfaces. What are the hallmarks of a good interface? Isn't it true that one interface might be well-suited for a specific purpose and not particularly useful for another purpose? If we "kludge" this interface to work for both purposes, aren't we creating conformity problems? Greg
There are four main areas which Brooks identifies as Problems.
- Complexity - The nature of computer softer is such that inorder for it to work correctly there must be main little parts. It is making these parts interact properly that aloows software to function corectly. The other part of compexity is that making a project larger is not js the repition of many existing parts, it often time is creating or revamping all the parts that all ready exist over.
- Conformity - Brooks states that a Software designer must adhere to interfaces that all ready exist. In other words software must have the look and feel of other software that is popular at the time. To some extent I agree with this, however often times it is this area that seperates one peice of software from another, and there bye giving it the advantage in the marketplace.
- Changability - Brooks mentions that most successful software projects evolve into something more over time. This is from users wanting to do more with the software framework that all ready exists. Brooks state that this is unique to the software field, since you do not often have a car getting upgraded with new functions in mid life. The other problem is that the architecture that the program is designed for is constantly evolving, and thus the software needs to be updated to keep up with these changes.
- Invisibility - This is the last Problem Brooks mentions. He says it is hard to chart the way a piece of Software is designed. There is no singular map, or blue print. Instead there are many. Brooks list items like name spaces, flow controal, time sequences, and patterns of dependecies as such examples.
I feel there is one major problem associated with Software design that Brooks forgot, and that is difficulty in testing software. Every user may use a piece of software in a different manner, and there for it is hard is not impossible to determine every possible senerio and test it. So making error proof programs is thus also very difficult.
Brandon Taylor
How do you think that testing influences the design of a software system? Can you give an example of how unit testing might change the way that you design software? (You might better be able to address this question after complete the first three laboratories that are inside of the Laboratory Listing). Also, you have brought up the appropriate consideration of testing in the presence of specific environmental considerations: many software testing researchers are discussing this right now! What are some environmental configurations that you envision must be tested? Greg
Complexity-Brooks points out that the complexity of software systems comes from the fact that nothing created in software systems is ever repeated. Granted, once a system is completed, it is easy to copy and distribute the software, but completing the software is the complex part. Each state, though different in construct, must fit together to create a working program, thus the complexity comes into fitting those pieces together to reach desired states based on various information.
Conformity-Brooks may have had this a bit backwards. He initially says that physics is governed by unifying principles, created, essentially by God. Thus the physicist is required to conform to unifying principles; he/she has no choice in the matter. Therefore it follows that software development suffers from an inherent lack of conformity (granted, Brooks points out that developers must conform to the systems with which they are working, but those systems were created without a basis of conformity, thus the larger issue).
Changeability-I'm not sure if this is a difficulty, or a blessing. The ability to make software changeable is a challenge, but the idea that software CAN be changeable is an attribute of software that, as Brooks points out, is seldomly shared among other manufactured products. But, the problem is that GOOD software is changeable, and there is no guarantee of GOOD software.
Invisibility-The lack of tangibility and the vastness of states is something that I think we may all have had trouble with at one point or another. For example, the queens problem was something I had much difficulty in solving because I had a lot of trouble picturing, even grasping, the progression to each state of the chess board. Brooks points out that software has "no ready geometric representation." Given inputs that the programmer may not have thought of, the software may be put in a state it is ill prepared for, simply because the developer couldn't "see" that state.
I can think of no other problems that Brooks may have missed. These four seemed encompassing but focused.
Matt DeNapoli
Brian Marick has recently begun a PhD thesis. He is interested in learning about "adequate representations" for programs; that is, something that is "good enough" to allow testers to effectively develop. What would a representation like this look like? Marick has also advocated the need for Tinkerable Softwarehttp://visibleworkings.com/tinkerable/dream.html, or software that can be modified by users. What do you think about this suggestion? It would enable software to better conform to the needs of users, but it might potentially create software that cannot easily conform to challenges down the road! Greg
- Brooks identifies several areas of computer science, such as object-oriented programming and artifical intelligence, as "hopes for the silver." Do you feel as though any of these areas are actually silver bullets? If no, is it possible that some of these technical developments could be considered "brass bullets" (i.e. techniques that might offer a notable, but less than order of magnitude improvement)?
I don't think that any of these "hopes for the silver" will ever turn out to be the cure all for software engineering. I do think that Object Oriented Programming combined with the grow not build field of thought has the most promise. With OOP you have a basic tool kit with specified interfaces that will allow designers to grow programs with out having to write a substantial amount of new code.
I don't think that buying verses creating software is a good solution for the silver bullet problem either. Buying software my solve the problem for your company but it doesn't do anything to solve the problem over all.
Jim Clause
My experience has been that the usage of COTS components (or SOUP) has been suspect at best. When you purchasae a COTS component, you need to think about the quality of this component. Moreover, you might need to remove some functionality from the COTS component or add new functionality. Generally, the research that has surrounded COTS components has been somewhat "soft." Personally, I have not seen signficant growth in this area! Greg
Ada was obviously not a silver or brass bullet. I think it is possible that Object-Oriented programming is a brass bullet. Its abstractions and hierarchies make code writing (details) easier but the majority of the work is the concept formation, in the case OOP - deciding how to break down the problem into classes and each classes' functions.
AI is not far enough along to really be considered for aiding software developement in my opinion. I don't think, right now, that AI could determine a problems specifications and form a concept to solve that problem (Essence). I do think that AI (or automatic programming) could be used as a silver bullet for the problem of details (of accidents). Just musing here, but take for example, given a set of basic machine instructions - AI could use a recursive algorithm Build Best Function to solve specific details in turn (ala how chess AI programs work - given a set of moves, Pick Best Move.) This would require breaking down the problem into many smaller parts though - by the software designer. If given rulesets (expert systems), the AI would only become more efficient (the best chess AI programs store many of the past Grandmaster chess matches.) A recursive function, given a set of inputs and acceptable states, could test every state of a program - verifying its correctness. This would reduce the accident part of Software Developement "to zero time" and in my opinion would be at least an order of magnitude faster (although requiring ridiculous, perhaps unfeasible, amounts of computation.)
As far as silver bullets for essence, Brooks has the closest solution I can think of right now: Grow, not Build. Writing a program from the top-down, a simple core root with many branches and leaves that add functions. This is simply a process of abstraction, similar to OOP. Very much like in Math, when you have a complex problem requiring a complex solution, break down the problem into its parts and solve each in turn. Start simply and build towards complexity.
Dan Fiedler
It seems like your discussion of automatic programming is very close to what genetic programming researchers are attempting to do (this is something that Chris McNamara alluded to in class today!). Hmm. You talk about "a set of inputs" and a "set of states" and then testing all of the states of a program. Do you think that this is really feasible? BTW, there is a large body of research that attempts to use model checking tools (like SPIN, and others) to ensure that a threaded-program does not enter into deadlock (see the Bandera research project). Do you really think that this is generally applicable? Greg
As of right now there does not exist any technology that could be considered a silver or even a brass bullet. I believe the closest thing is object oriented programming. With object oriented programming code reuse is emphasized so larger projects can actually be put together rather easily. As far as the future is conserned I feel that eventually(rather it will be in my lifetime I am not sure) there will be AI good enough that it will be possible to enter in a problem and have a program generated to solve it. I feel this will be the silver bullet that everyone is looking for.
Brandon Taylor
I think that reuse is probably important. But, our reuse is stuck at the point of "list" or "stack" and not at the point of "user interface". Is it possible to make the large jump from reuse of small components to the reuse of much larger components? In some sense, is this was COTS components are all about (i.e. buy vs. build)? Greg
None of the "Hopes for Silver" that Brooks presents attack any of the essential difficulties of software development. He actually proceeds to make these suggestions of expert systems, graphical programming, program verification (testing), etc. and then tears each one down as to why they fail to be that "silver bullet." Granted, there is the theorectical potential that artificial intelligence might be able to reach a point where given a problem, that software itself can create the specifications and design to create other software to solve a given problem. But then that would mean that machines could "think", and we would have no hope of finding jobs. From that, there is also the possibility of the grey goo effect where the machines take over the world, use up all the earth's resources creating each other, kill off humans and take over the world matrix style. AHA, but therein lies the question itself...without a "silver bullet" can such a "silver bullet" be attained?
Matt DeNapoli
Okay: so, is there some point where software engineers will be looking for work because AI has evolved to the point to which you are referring? What is this "theoretical potential" that you are referring to? What is AI? Greg
Link to this Page
- Introduction to Software Engineering last edited on 30 August 2004 at 1:12 pm by aldenv28.allegheny.edu