The Mythical Man-Month Ch. 18-19

The Mythical Man-Month
Ch. 18-19
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

The author begins chapter 19 by discussing how the mythical man month applies not only to software engineering teams but to teams of all backgrounds. The author then goes into detail about the importance of conceptual integrity in software. Projects with fewer designers typically have more conceptual integrity and are better designed as a result. For example, off the shelf software products often suffer from a low conceptual integrity because they are built to appeal to a wide audience rather than being architected for an express purpose.

The author also discusses the recent success of the WIMP model (Windows, Icons, Menus, Pointers) in computing. However, due to WIMP's limitations the author believes that it will soon be replaced with a new model.

The author also came to an important realization about his initial suggestions to plan to throw the first design away. The author now endorses building the system incrementally, testing each individual component as it is added to the system.

The author ends the reading by noting the dramatic rise of personal computers and software that are available to the public today. When the book was originally written, the author focused on custom built software that would not be available to the public. However, the increased amount of customers that software developers have today allows them to receive a large amount of feedback on their products but also requires them to test more thoroughly before releasing it.

Discussion:

This reading is important because it discusses how software has changed since the book was originally written. The author discusses many important trends in software engineering and offers his ideas on the future. I disagree with the author's ideas that the wimp model will be obsolete. I believe that portions of the model, such as the pointer, may be phased out but many of the core components will stay. This reading can be used by anyone in a software engineering team environment.

The Mythical Man-Month Ch. 16-17

The Mythical Man-Month
Ch. 16-17
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

The author discusses the difficulties related to software engineering and how there is no single "silver bullet" solution that will cause a large increase in productivity. The author splits the characteristics of software engineering into two groups, essential and accidental. Essential characteristics are those that are characteristic of software engineering and will not be fixed in the future. Accidental characteristics are the issues that face software engineering today but are likely to be fixed in the future. There have been several advancements in recent years that have helped to reduce the accidental difficulties related to software engineering, such as high level languages and time sharing.

The author does offer some suggestions to help combat the decreased productivity caused by the essential characteristics of software. For example, buying premade software components can drastically reduce the time spent designing and implementing complex software. The author also suggests using incremental development and prototyping in order to create a better specification of the program before building it.

In chapter 17 the author looks back at the silver bullet paper and observes that no silver bullet has been created yet. The author also goes into detail about the difficulties of correctly using object oriented programming and designing reusable components.

Discussion:

This reading is interesting because it offers a more pessimistic perspective on the advancement of software engineering. I did not like the fact that the original paper was written so long ago that it seemed obsolete. This writing can be used by anyone in the software engineering field looking to increase productivity.

The Mythical Man-Month Ch. 13-15

The Mythical Man-Month
Ch. 13-15
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

Chapter 13 discusses methods for testing, structuring, and debugging software projects. In regards to system structure, the author advocates a top down approach where the components of the system are defined and then broken down during "refinement steps". In regards to debugging and testing, the author believes that components should be debugged separately at first and then integrated one at a time in order to test the system as a whole. The author also advocates writing scaffolding in order to help test the code thoroughly and completely.

Chapter 14 focuses on milestones and how they can be used to keep projects on track. According to the author, milestones should be taken very seriously and missing one could indicate bigger problems in the project. The author suggests that managers should use a PERT chart to help avoid missing milestones. It is also the managers job to encourage communication between team members and to provide disincentives for team members who hold a project back.

Chapter 15 discusses how code can be used not only to communicate with computers but with other programmers as well. In order to communicate ideas effectively through code it must be easy to understand and follow. The author also describes certain items that should always be well documented, including IO formatting, descriptions of algorithms, options, range of input and output, etc. Instead of relying on external forms of documentation, the author suggests writing self documenting code by choosing descriptive variable names, using correct formatting, and including descriptive comments.

Discussion:
This reading is useful because it discusses the need for communication when working in team environments, especially through code. I believe that well written code can save programmers from having to verbally explain their code to everyone that needs to use it. I did think that the author could have spent more time discussing how systems can be designed in order to make testing easier. This reading is useful for managers, designers, and programmers since the reading applies to all three positions.

The Mythical Man-Month Ch. 10-12

The Mythical Man-Month
Ch. 10-12
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

Chapter 10 discusses several methods that teams can use to document projects. A team can collect documentation in the form of objectives, specifications, budgets, schedules, organization charts, space allocations, and estimate prices. The authors uses a university department as an example to show the necessary elements needed to properly document a project. The author ends the chapter by explaining how proper documentation can help reveal problems with the project, such as design errors and inconsistencies.

Chapter 11 returns to the concept of writing prototype systems with the intention to be thrown out before writing the actual system. Since this process takes more time it is likely that requirements will change and new features may be added. To help adapt the code to new requirements the project should be designed in a very modular fashion with the ability to add and remove modules without crashing the system or needing significant rewriting of the code. The author ends the chapter by discussing the importance of writing maintainable code, stating that code maintenance can often be more costly than the development of the code itself.

Chapter 12 discusses tools that teams need to use to finish the job. The author discusses how tools should be shared instead of used by individuals in order to encourage communication. The author also encourages the use of high level languages to increase productivity and communication through code.

Discussion:

This reading is interesting because it discusses the need for documentation and the right tools in order to get the job done. What I did not like about the reading is that all of the ideas seemed like common sense, especially the ones regarding the need for documentation and tools that everyone can use. This reading can be used by teams that are planning on what tools they need to acquire before beginning the development of a software project.