The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995
Summary
Chapter eighteen serves as a summary of the key points of all the previous chapters. For the sake of brevity, this chapter will be ignored since it was all covered before.
Chapter nineteen presents the author's views on the effect of The Mythical Man Month on software development (and in other fields as well), how its concepts have held up, discussion on the changes that have affected the industry, and the future. The author states that the book's success in multiple fields can be attributed to the fact that the concepts apply to any team-like organization.
Conceptual integrity is the most critical facet of any product. The best way to maximize conceptual integrity is to have as few people design the software as possible. These people are called architects. The architecture, or design, of the system should be separate from its implementation. Therefore, the master architect should partition the overall system into smaller self-contained subsystems.
Off-the-shelf applications have started to replace custom implementations in many situations. These programs are prone to suffer from featuritis, where insignificant features make using the software harder or less enjoyable. To help overcome this, it is helpful to define the expected user, especially in these areas: who they are, what they need, what they think they need, and what they want. These can even be guesses, but they must be as detailed and explicit as possible.
The author discusses the explosive success of the Windows, Icons, Menus, and Pointing interface (WIMP) model for computing. He says that the WIMP model exhibits excellent conceptual integrity. There are some limitations to the interface: the author presents the problem of using two mice simultaneously and other annoying aspects. He expects the WIMP interface to be phased out within a "generation".
The author admits that his previous assertion that using the Waterfall Model in conjunction with throwing the first attempt out is completely wrong. Instead, he now believes that an incremental build model is better. First, a skeleton system should be created, with all of the functions existent but doing nothing. With this in place, testing can be accomplished from the very beginning of the project. Afterwards, the function stubs can be filled out with working code while being tested constantly. At every stage of development, the system should be running without error - even if it does not do anything useful. In addition, the author advises that the engineers should design the product as a family of related projects instead of one large project. The author also agrees with a certain critic that it is better to practice information hiding than to expose all of the internals to every programmer.
Some data that had been generated since the publication of the book in support of the mythical man-month concept is presented. It concludes that adding more people to a late project does not necessarily make the project later, but does make it more costly. The quality of the programming team is by far the most significant variable for determining the chances of success for a project.
A more decentralized organizational structure is recommended because the increased freedom allows the programmers to be more creative an enthusiastic - much like small startup companies. The true advantage to this, from the managerial point of view, is that their power actually increases as they allow the programming teams more license.
The author says that the biggest surprise development was the sheer number of computers that are now available. The average American can now afford to own a personal computer, along with a vast array of software. All of this would have been inconceivable at the time of the original publication. This revolution has fixed many of the accidental problems with the software development process. Now, software can be developed and sold at a large scale, which minimizes costs.
Lastly, the author discusses shrink-wrapped software. Using components that have been thoroughly tested decreases development time and effort. Metaprogramming is also introduced as a most favorable feature for a wide range of software.
Opinion
These chapters acted mostly as a summary or recap. The author admitting that some of what he advocated in the original book was incorrect added nice variety to the last chapter. It was nice to see that the modern incremental build system was presented as the recommended paradigm,
Incremental building
No comments:
Post a Comment