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.

The Mythical Man-Month Ch. 7-9

The Mythical Man-Month
Ch. 7-9
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

Chapter 7 focuses on the need for communication while working on team projects. The author first discusses the Tower of Babel as an example of when communication, rather than time and resources led to the failure of a project. Teams are often comprised of several  people working in different specialized roles. This differentiation makes communication important because the team needs to understand the status of the project as a whole and how they are going to combine their individual parts. The author suggests using meetings and workbooks to achieve this communication. The author especially stresses the use of a workbook because it gives the most detailed documentation of a project.

Chapter 8 discusses the need for correctly planning and budgeting projects. According to the author, only a sixth of the total development time should be spent on coding. This is due to the fact that many inaccuracies and bugs will need to be fixed before the final release of the project. Multiple projects being developed concurrently can also cause a hue increase i development time.

Chapter 9 discusses the importance of correctly budgeting the system requirements of components. The system requirements, such as hard drive space requirements should be determined by analyzing the systems of the users. The system should be designed with the space-speed complexity trade off in mind. That is, in most cases the more space a system takes the faster it will run. The system designer should design the components of the system to not exceed the space limitations of the users and at the same time not make the system so slow that it is unusable.

Discussion:

This reading is interesting because it discusses several trade offs that system designers should consider when designing a software system. I do think that several of the points made were common sense for the audience of the book. This work can be applied to anyone who is designing a software system or is going to be managing the development of a software system.

Extreme programming installed Ch. 22-24

Extreme programming installed
Chapters 22-24
Ron Jefferies, Ann Andreson, Chet Hendrickson
Editors: ?

Summary:


Chapter 22 focuses on defects. The authors describe defects in a similar way to user stories. For instance, defects should be written onto note cards and given to the person most appropriate to fix them. Defects are also scheduled to be fixed in iterations and can be prioritized based on importance or the length of time it will take to fix the defect. If any defects manage to get through unit and acceptance tests then those tests need to be fixed in order to prevent new defects from being added to the code base.


Chapter 23 is very brief and discusses the values of extreme programming. These values include communication, feedback, and courage. The authors conclude the book by offering recommendations and discussing practices that reiterate ideas discussed in earlier chapters.


Chapter 24 discusses the aspects of planning and user story estimation. During the planning phase the authors suggest estimating time to be 3 times as long as it would take if the programming team were to work the entire day uninterrupted. The authors also discuss the need for open communication between the programming team and the management. The team should be able to give practical estimates of user story completion times to the management without being pressured into giving lower times than they can produce. This aspect is important in scheduling a plan that will be practical to complete without overloading the programming team.


Discussion:

This reading is interesting because it goes into detail about how to find and eliminate defects. I have never used a note card system for tracking bugs but I think that having something physically in your possession to indicate the need for you to fix a bug would be useful. Aside from the bug tracking chapter this reading felt like a repeat of previous chapters with very little extra information. This reading can mostly be applies to management that want to schedule a software project or want to include defect fixing into their schedule.

The Mythical Man-Month Ch. 4-6

The Mythical Man-Month

Ch. 4-6
Brooks, Frederick P
Addison-Wesley, 1995

 

Summary:

In chapter 4 the author discusses the importance of system design. According to the author, the design of a system's architecture is one of the most important aspects of a software project. As a result, the architecture of a system should be designed by as few people as possible. The author also discusses the importance of usability in the system's design. According to the author it is more important to achieve a more usable system rather than a system that has a large amount of features but is difficult to use. The author also suggests that the design of a system and the implementation of a system be handled by at least two different people.

In chapter 5 the author discusses second systems. According to the author, a designer's second system is more at risk of mistakes than his first due to the fact that the designer will take the knowledge gained from his first attempt and immediately apply it to the second attempt. This can cause the designer to not put enough time and effort into the design. To remedy this the author suggests that designers create a throw-away implementation before designing the actual system. This will allow the designer to spot flaws in his design and will hopefully cause him to be more careful on his next attempt.

Chapter 6 focuses mostly on documentation for software projects. The manual is the documentation that the end user will be seeing. The manual should provide a reference to everything that the user can interact with but should not go into implementation details or anything behind the scenes. The author suggests that the code of the software is the best definition of the software but is not a practical means of documentation.

Discussion:

This reading is interesting because it discuses the importance of system design to the overall success of a project. However, I think that having different people or parties designing and implementing the system can be just as troublesome as having the same person design and implement the system. Personal conflicts or poor communication can cause projects to fail when different parties design and implement the software. This work can be applied to designers who are beginning to design a software system.