The Mythical Man-Month, Chapters 18-19

Reference Information
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

The Mythical Man-Month, Chapters 16-17

Reference Information
The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995


Summary
Chapter sixteen postulates that there is no innovation on the horizon that will fix the core problems of software development, which the author terms a silver bullet. The author advises developers to purchase already constructed components on the market, to use rapid prototyping, to grow software instead of building it, and making use of interactive and conceptual designers. Software encompasses properties that are either essential or accidental. Complexity is an essential characteristic of software - it will always be so. Accidents are difficulties that exist now but could be rectified in the future. The author believes that the hard part of creating software is the design, specification, and testing of the conceptual construct, not the implementation. Much complexity is created by pre-existing interfaces, which cannot be fixed by redesigning the software. The software itself is under constant pressure to change. Useful software is updated constantly to fix problems and add features. Another difficulty is that software lacks true substance - it cannot be visualized. The author says that this fact deprives the human mind of a powerful mechanism to reason about the structure. Breakthroughs made in the past had solved some of the accidental difficulties of software; the author lists:

• High-level languages - the most powerful advance; increased productivity, reliability, and simplicity
• Time-sharing - increased productivity and quality of product
• Unified programming environments - providing fixed interfaces, libraries, file formats; Unix, etc.

Next, the author lists some potential silver bullets:

• Ada - encourages modern program design, but the author thinks it will not have much effect
• Object-oriented programming - the author believes this holds great promise
• Artificial Intelligence - the author does not think that this will make much improvement
• Expert systems - inference engine based on rules garnered from experience. The author thinks it will be helpful for novice programmers 
• Automatic programming - creation of a program from its specification; unlikely to be successful
• Graphical programming - create program visually; software is difficult to visualize, however
• Program verification - can be done, but will only verify that it meets specification, not that it is right
• Environments and tools - better tools would enable better productivity
• Workstations

Lastly, the author lists some methods by which the essential difficulties of software engineering can be lessened:

• Buy versus build - purchasing pre-made components instead of building them
• Requirements refinement and rapid prototyping - allow the program to change as the needs change
• Incremental development - growing the program instead of building it. It is too hard to accurately specify a program before building it. The system should always work, even if it does nothing useful. This method enforces top-down design.
• Great designers - good designs come from good practices, great designs come from great designers

Chapter seventeen serves as a rebuttal to criticism for the previous chapter. It mostly comments upon additional studies done in the field and defends the positions presented before.

Opinion

Most of the objects from his silver bullets list have had substantial improvements since the publishing of the book. More interestingly, three out of four of the remedies for the essential software development process have become recommended practice in the field. Great designers, on the other hand, is very subjective and is very hard to determine if improvement has been made in this area.

The Mythical Man-Month, Chapters 13-15

Reference Information
The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995


Summary
Chapter thirteen discusses how programs should be designed and built, along with using milestones to measure progress and completeness. The most common bug arises from misunderstandings between authors of different components. The outward-facing functions and definitions of each component should be meticulously documented. To ensure quality, the fully-formed specification should be looked-over by outside experts. The author emphasizes the need for top-down design. Top-down design is a processes whereby a broad task definition is made and then subsequently refined in many steps that each focus on a smaller and smaller portion of the design. The author believes that this system was one of the most important advances in software engineering. Structured programming is important for creating program flows that are easy to follow, including removing most of the uses for GOTO statements. Interactive debugging, which is provided by most modern languages, enables the developers to find and fix problems rapidly. Plenty of code should be written for testing the system, which the author terms scaffolding. Each component of the system should be tightly controlled by one person who must approve any changes. Along with this, only one component should be added to the system at a time.


Chapter fourteen, entitled Hatching a Catastrophe, discusses milestones. Milestones are a result of having a schedule. They must be concrete and very specific. Milestones can indicate a transition between the phases of planning, coding, and debugging. Each slip of the schedule must be treated as a serious incident. The author recommends using a PERT chart to maintain the schedule. A PERT chart is created by creating three estimates for each event and combining them with three probabilities of reaching completion dates. Simply preparing the PERT chart gives a large benefit to the project.


Chapter fifteen, The Other Face, introduces various techniques for documenting code. A program is communicating both with a machine and also with other people. Therefore, it must be documented in plain language for them to better understand. Various things that need to be documented are purpose, environment, domain and range, functions/algorithms, I/O formats, operating instructions, options, running time, and accuracy and checking. Programs must be supplied with test cases so that the user can be sure that it is functioning properly. For future modification of the program, a flow chart should be provided that explains how the program works. However, the flow chart should only be a high-level overview, too much detail only interferes with understanding. The author recommends using self-documenting code where possible. This includes moving all documentation into the code files themselves. The variable names and formatting of the code can help as much as additional documentation.


Opinion
Most of what was presented has entered into mainstream programming thought since the book was published. We were taught about self-documenting code in our courses in school. The top-level design process appears to be the most natural way to attack large programs, so that they can be broken down into more manageable chunks.

An example PERT chart

The Mythical Man-Month, Chapters 10-12

Reference Information
The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995


Summary
Chapter ten, entitled The Documentary Hypothesis, discusses the need for extensive documentation during the development process. Documents that should be generated include the objectives, specifications, schedule, budget, organization chart, space allocations, and estimate prices. These documents collectively answer the questions what, when, how much, where, and who. Writing these documents will help expose inconsistencies in the product. In addition, the documentation facilitates communication and provides a convenient checklist of features. 


Chapter eleven is about the need to write a prototype system whose function is to expose most of the implementation issues that could not be foreseen. The author likens this to how chemical engineers must design and build a smaller pilot plant before building the real thing as a proof of concept. The first system build is rarely usable as a product. Therefore, management must plan to build the product twice, if it wants to deliver a remotely decent product. Another problem that frequently occurs is that the requirements for the software change during the development process. To counteract this, the software should be very modular so that any required changes only affect a small portion of the project. The whole organization must also be able to be flexible and to withstand change. The author gives examples of some companies abolishing all job titles: without a title, everyone has equal responsibility. Change continues even after the delivery of the "final" software. The cost of maintaining software can easily be 40% more than the cost of actually developing it. Since many of the people who maintain the software were not on the original programming team, many additional bugs may be introduced in the maintenance phase. Each defect that is fixed has a large chance of introducing another such defect. Even worse, constant fixing-up and patching will destroy the structure of the original program.


Chapter twelve discusses the need to use tools appropriate for the job. Most tools should be shared by the entire team. If each person on the team uses different tools, it dampers communication and efficiency. Common tools need to be found or created that satisfy the entire team. The author discusses many considerations that were relevant a very long time ago, but are omitted here. He says that it is far better to create too much documentation than to not fully document the software. Using a high-level language is crucial, along with interactive programming.


Opinion
Writing a prototype system and then throwing it away seems like an enormous waist of time, except that I have personal experience in this matter and can say that he is absolutely right. Many times, the first implementation uncovers many design flaws and pushes the software in a new direction.

The Inmates Are Running the Asylum, Chapters 8-9

Reference Information
The Inmates Are Running the Asylum
Cooper, Alan
Sams Publishing, 2004


Summary
Chapter eight discusses how an elitist culture has formed around software engineers and the negative effect that this culture has on the end-users. Engineers value program efficiency over the needs of the user. Programmers also like to reuse code that was already written to save effort. Sometimes this code is of questionable quality and is merely copied over and over again by many people because it was already written. This illustrates the conflict between what the programmer wants (ease of implementation), and what the user wants (ease of use). There is a reverence in the industry for technical skill. Therefore, the most talented and experienced programmers are exempted from helpful duties such as answering customers' questions. This actually insulates them from understanding what the customer really wants. The author believes that the mindset that is so prevalent throughout the industry of the need to preserve resources (what he calls scarcity thinking) hampers the improvement of interaction design by keeping the focus on technical details.


Chapter nine, entitled Designing for Pleasure, introduces the concept of personas. A persona is a precise description of a user and what he would want to accomplish. Simply asking the real user typically yields poor results; the user does not really understand the problem. The users that are used for designing the software are entirely fictional. In fact, it is far better to design for only one of these personas. Having a small percentage of the total market absolutely love your product will guarantee success, as was discussed in an earlier chapter. In this way, designing for one user is actually the best way to design for the population at large. The more specific the persona, the better the results will be. Giving each persona a name is one of the most important parts since it begins to build the character of the user. Counter-intuitively, it is more important that the persona to be specific than to be the most accurate depiction of an actual user. Having personas allows the team to openly discuss the various skill levels of the users - this helps avoid writing the product for super-users. They also allow for easy determination of required features; programmers all-to-often want to make the software too general. The persona should not target the buyer since it is the actual user that matters. The author recommends creating between three and twelve personas per each project. However, only one of these will be the "primary persona". This is the user whose needs trump those of all of the others. This persona must be absolutely satisfied with the end product.


Opinion
Chapter nine was quite fascinating, apart for the ridiculously long example. The idea of personas - and that the software should be designed for only one user - seemed enormously useful. This is something that I would like to apply to my own projects.

I don't know what this is, but it says Persona, and that's relevant

Extreme Programming Installed, Chapters 28-30

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000


Summary
Chapter twenty-eight, called Balancing Hopes and Fears, gives an example from the author's past. His team had decided to retain certain legacy reporting procedures from some software that was being replaced to help with a faster transition. The team did not understand much of the older system, even the parts that they were hanging on to. This fact is not documented on any charts, and was hanging over the team's heads as they approached delivery. However, the team decided to come together and discuss the problem so that the team could be more confident in themselves. The situation arose because there was a large portion of the code which had no acceptance tests since they were legacy.


Chapter twenty-nine, entitled Testing Improves Code, presents a very short example from Rich Garzaniti. The premise is that Rich had to refactor some troublesome code. Upon writing the tests, he discovered that a method needed to be modified and moved some code into a helper function. This change made the code simpler and more easy to understand. The author says that code that cannot be easily tested is typically not refactored properly. He also says that writing tests first will ensure that these situations do not arise frequently.


Chapter thirty presents an example from using extreme programming with Java. A corporate database system was being replaced by a newer one and the author's team was responsible for writing the replacement. The project used Javascript and LDAP. At first, each code change required up to ten minutes before its results could be seen. In addition, the poor setup led to many files being corrupted. The author downloaded a debugger and started writing test cases and was able to get the system straightened out relatively easily. By using testing and refactoring he was able to fix the system and also make future changes that much easier.


Opinion
There is no relevant material to evoke any sort of interest or opinion. The examples are very simple, yet dense, and do not offer anything that was not already presented earlier in the book.

The Mythical Man-Month, Chapters 7-9

Reference Information
The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995


Summary
Chapter 7, with its title asking Why Did the Tower of Babel Fall?, discusses the importance of documentation, communication, and organization. Teams communicate informally, meetings, and through workbooks. A project workbook is extremely important: it answers what, why, and the mechanics of the project. Communication is critical with the advent of the division of labor and specialization. Each person knows what only small parts of the whole project are doing and needs to communicate with others for the other parts. The author gives various situations that can occur between the producer and technical director.


Chapter eight, entitled Calling the Shot, talks about estimations and their inaccuracies. Coding should only be budgeted for about one-sixth of the development time of a project. The estimated development time for small projects cannot be interpolated to anticipated the cost of large systems. Testing showed that many programmers were underestimating the time to accomplish tasks by almost half since they did not consider that they would have many other obligations as well. Data supporting these conclusions from Aron, Harr, the O/S 360 project, and Corbato was presented. It is also asserted that using a suitable high-level language can increase productivity by as much as five times.


Chapter nine is called Ten Pounds in a Five-Pound Sack. The chapter discusses space complexity and planning. The design team must set targets for the space allowed for each component of the system. Controlling size involves studying the users and what applications they use. In addition, each component needs to have a set access budget (for things like the hard drive). To help estimate, what each component does needs to be well-specified beforehand or the estimation will be very inaccurate. However, using more space can increase performance of the system. Much improvement can be made by redoing the data representation format.


Opinion
Most of these chapters are highly out-of-date (it talks about typewriters...). Very little can be gleaned from its pages other than intellectual curiosity at the state of the industry thirty years ago. Most of what is expounded here goes against modern advise such as Agile development.

 This book is out-of-date