Software Engineering discussion

The Mythical Man-Month > No Silver Bullet-Essence and Accident in Software Engineering

Comments Showing 1-3 of 3 (3 new)    post a comment »
dateDown arrow    newest »

message 1: by Erik (new)

Erik | 165 comments This chapter seemed oddly familiar to me as I read it. Near the end, I remembered SEIS610 had an assignment to read and report on this article. I dug up my old essay. I will post it.

It's interesting to me to read and review how my viewpoint has changed after just a few years.

message 2: by Erik (last edited Jan 03, 2011 08:13AM) (new)

Erik | 165 comments The No Silver Bullet: Essence and Accidents of Software Engineering article is Frederick P. Brooks Jr.’s thesis regarding software engineering, its difficulties (essential and accidental), and solutions to the difficulties. He examines the nature of the software problem and the properties of the solutions, which he refers to as silver bullets. Although there are many encouraging innovations occurring at the time the article was written, the author feels there is no single break though to be made in either the technology or management side that guarantees one or more orders-of-magnitude improvements in software development. Brooks feels that the most difficult part of software development are the architectural tasks such as specification, design, and testing the conceptual construct.

The difficulties are divided in to essential and accidental types. The essential problems being innate to the nature of software: a complex and precise abstract construct derived from sets of data, data items, algorithms, and functions. The accidental difficulties being those problems that occur when developing software, but are not innate to software itself. He lists the essential difficulties as complexity, conformity, changeability, and invisibility. Accidental difficulties are not listed as clearly. Instead, breakthroughs aiding accidental difficulties are discussed.

Software’s complexity being among the most complex thing people create and increases non-linear with its size. The extreme complexity causes challenges of communication, verifying all scenarios, usage, adding new features without unwanted side effects, and security concerns. I agree that complexity of software causes these issues. This continues to be a relevant issue in software engineering today as it creates the same challenges. It’s hard to imaging a silver bullet solution to complexity, and Brooks does not provide any.

Conformity is a necessary quality of software for a variety of reasons, which include user interaction, interfacing to existing software, or extending existing functionality. Conformity can not simply be designed out of software, but design consideration can reduce the complexity of conformity challenges. I believe conformity to be a necessary quality of software, and feel it has only become more important since the time the article was written.

Changeability is listed as an essential difficulty for software development, because all successful software gets changed, customers change their requirements, bugs are fixed, and software is infinitely malleable. I agree that changeability is an extremely important characteristic of good software, and in the real-world changeability happens and is an essential difficulty. In an ideal world, one could argue that changeability is not inherent to software because there would be no bug, no change of requirements, and no need to change the software. Since we live in the real world, changeability will continue to be an essential part of software engineering practices.

Invisibility is the last essential difficulty that Brooks lists. Geometric abstracts, blueprints, flow charts, and models aid in visualization of software. Creating, reading, and communicating these visualization aids add complexity and opportunity for errors. I feel this is a sub-type of the essential complexity difficulty and continues to add difficulty to modern software development.

Three solutions to accidental difficulties are discussed as breakthroughs. They are High-level languages, time-sharing, and unified programming environments. High-level languages are the most powerful of these three breakthroughs for productivity, reliability, and simplicity. The high-level languages provide powerful common constructs to the programmer and reduce a level of software complexity that is accidental. There is a limit to how much aid a high-level language can provide before it becomes a counter productive burden of tool-mastery. I agree with this completely, and feel the amount of improvement high-level languages can continue to add is flattening out. My programming productivity would fall dramatically if I had to write assembly instead of C/C++. I usually don’t feel it necessary to use C# for tasks that C/C++ are perfectly suited for, so some “higher-level” languages don’t add enough incentive to use. Time-sharing is a fine improvement in productivity and preservation of a programmer’s time. Brooks claims the threshold of notice ability to be around one hundred milliseconds, and I feel that modern personal computers and development environment are at that threshold now. Time-sharing continues to be an important breakthrough, but the breakthrough can do no additional amount to reduce software engineering difficulties. Unified programming environments is the final breakthrough listed that attacks the accidental difficulties of software engineering. Integrated libraries, unified file formats, along with pipes and filters resulted in suites of tool benches that could be applied to programs that conformed to the standard. Unified programming environments’ promises and limitations are discussed in the Hopes for the Silver section of the article. I feel that unified programming environments are extremely powerful tools for a developer to have, and they have reduced the amount of accidental difficulty nearly as much as high-level languages. These environments continue to get more complex, and I think it will be limited by the burden of tool-mastery much the same way high-level languages are limited.

The Hopes for the Silver section lists areas for possible future advancements as high-level language advances, object-oriented programming, artificial-intelligence, automatic programming, graphical programming, program verification, environment and tools, and workstations. He was not expecting advancements in the graphical programming area, but Visual Basic is an example of graphical programming carries some fame today. Complete program verification can be so overwhelming that he yields little hope of ever truly tackling this task. I feel many verification automation and test coverage detection advancements have been made that give an improved level of verification. Test and code coverage detection attacks the complexity problem inherent to program verification. Environment and tools, high-level languages, and workstations are respectively analogous to the unified program environment, high-level languages, and time-sharing breakthroughs discussed earlier. The high-level languages and environments have certainly improved since the time this article was written, but it’s hard to say if they can be put in the silver bullet category. Workstation improvements appear to be at the limit of attacking the time-sharing challenges, and I think this has been the case for at least seven years. Object-oriented programming seems to be his strongest hope for future breakthroughs, because it addresses every challenge essential and accidental to software engineering. I agree that object-oriented programming and design is a superior approach to attacking the software development difficulties.

Brooks lists promising attacks on the essential difficulties as the following: buy versus build, requirement refinement and rapid prototyping, and great designers. If one is able to buy existing software rather than develop from scratch, the pains of design, research, development, testing, documentation, and support are avoided for a known and fixed cost. Software replication is cheap, and buying rather than building will most often be cheaper and more predictable. Requirements refinement and rapid prototyping sounds like a description of agile-scrum programming. This says that trying to have working software as early and often as possible (even with limited functionality) encourages the programmers and helps customers verify the product will meet their needs. Lastly, great designers are touted as at least an order of magnitude greater than good designers. There is a creative element that Brooks claims good designers can not be taught, and we must identify potential great designers early as they are not always the most veteran engineers. I agree that buying rather than building and agile programming are easy to implement and important factors to making successful software. Great designers are important to great software, but they can be more difficult to identify and apply than buying software or implementing a development process.

message 3: by Brad (last edited Jan 12, 2011 04:32AM) (new)

Brad (bradrubin) | 264 comments Mod
Thanks for posting your essay, Erik. I think that it summarizes this important paper well. Brooks' paper should be required reading for all software engineers.

There is a time warp, of about a decade, jumping from the previous chapters to this one. So, OS/360 references disappear and UNIX ones come to the forefront. This paper has been very influential, sparking much discussion and debate. Reading it again today, I am amazed at how prescient it was. Much of what it said is still true decades later. Some view this as a pessimistic commentary on our profession, others view this as a realistic one. This is discussed in more detail in the next chapter.

Personally, I think that our craft is getting easier in some ways, and more difficult in others. The rise of high-function frameworks, such as we find in iOS/Android, is a real boon to productivity. On the other hand, dealing with multi-core and concurrency and security and standards will take a toll on future productivity.

As Brooks discusses in the next chapter, the terms "accidental" and "essential" are too abstract in this essay. What Brooks is really doing here is applying Amdahl's Law, originally meant to characterize the overall performance speedup of hardware when only part of it gets a performance boost. If the requirements and design phases cannot be done more efficiently, then even dramatic improvements in the implementation phase will not significantly affect overall productivity. This leads to the buy vs. build, use generic tools (i.e. spreadsheets), and reuse (which hasn't really panned-out) strategies.

back to top