The Mythical Man-Month Ch 18-19

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 18 discussed the main points from the 1975 edition of The Mythical Man-Month in outline form. This included bulleted points of the most important points from each chapter that the author believes to be true, along with the author's commentary. Most of the points were thoroughly discussed in previous chapters.

The cover to the 1975 edition of The Mythical Man-Month. Source: http://var.pulist.net/

Chapter 19 discussed the differences between the 1975 edition of The Mythical Man-Month the state of things 20 years later. It considered the reason why the book is still relevant. Then, the central arguments of the book were considered: the importance of conceptual integrity, the need for an architect on the design to ensure conceptual integrity (including his separation from implementation and the partitioning off of subsystems. The Second System effect was discussed more, taking into account challenges such as designing for large-user sets, dealing with featuritis, the need to explicitly define the user set, and the benefit that defining frequencies of the user set has on the design. The WIMP (Windows, Icons, Menus, Pointing) interface was discussed along with its good and bad points, such as conceptual integrity via a metaphor, user power, and the fact that the author believes it will eventually become obsolete. The author encourages incremental building instead of the waterfall method that is supported throughout the book. Finally, he discusses the importance of people to a project, data that supports his conclusions, the effect that new technology has had (including the tendency to buy and build new software), and what he believes will occur in the future.


Discussion
I thought that chapter 18 was a good summary of the current book, although after having already read the book, it seemed a little unnecessary. I did like the chapter 19 discussed the points made throughout the book in a different light, encouraging the reader to follow practices that the author believes is good given new data and new technology. However, the author debunked many of the things said throughout the book by switching to supporting the incremental build instead of the waterfall method. I thought this made some of the chapters and points that he had made rather pointless, so I wonder what the point of reading them was in the first place? Either way, though, there were some very good points made within this book. I was previously unaware of many of the things discussed (such as the second system effect), so I believe that applying this information to future projects will be very helpful, including incremental programming, being aware of featuritis, and keeping many of the organizational structures that were recommended in mind.

The Mythical Man-Month Ch 16-17

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
The first chapter was "No Silver Bullet", a paper written in 1986 about the state of programming and the lack of a magical solution to improve programs by an order-of-magnitude. There are two major types of difficulties with software: essential (difficulties that are inherent in the nature of software) and accidental (those difficulties that attend to production but are not inherent). Complexity, changeability, conformity, and invisibility are all essential challenges that come with programming and must be considered. Breakthroughs that have been helpful in improving accidental issues associated with programming include high level languages, time-sharing, and unified programming environments. The author discussed topics that show promise for improving software, such as AI (he did not think this would be helpful) and object-oriented programming. The most promising improvements are the fact that general software can now be bought for cheap, incremental development, and developing great software designers.

There is no silver bullet, magical solution. Source: socialwants.com

The second chapter was the author's evaluation of the "No Silver Bullet" paper. He defines many of the terms used in the paper in terms that he finds to be more understandable and evaluates a few other peoples' critiques of "No Silver Bullet", including the idea that productivity follows from quality of software. The buying instead of  building of general software is recommended and object-oriented techniques are praised. The idea of reusing code is considered, which requires more expense up front and larger vocabularies to learn.


Discussion
The "No Silver Bullet" paper presented some interesting ideas, such as the idea that there is no magical solution to solve all software issues. However, the paper was so out-of-date for present time that it made it seem rather pointless to read. The object-oriented programming discussion was outdated since it is currently in use, and the argument that graphical software is pointless due to small screens is rather moot now. However, I did like the idea of incremental development, as it seems like what we are currently doing with our Capstone project, incrementally issuing working versions of our product that slowly increase in functionality.

Also, the author's discussion about the paper seemed rather odd, since he was critiquing critiques of the paper. Also, the even these arguments were slightly outdated, especially the arguments that object-oriented programming can be infeasible due to training costs; today most programmers are taught object-oriented programming from the start. Once again, though there were some helpful points, including the suggestion to buy software instead of creating specialized, expensive software tools. This information could be applied to future products to keep in mind that there is no magical solution, but there are many helpful tools available to use.

The Mythical Man-Month Ch 13-15

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 12 discussed how the parts of a program fit into the whole. It mostly focused on eliminating bugs. It is suggested that to reduce bugs in a program, the definition should be bug-proofed, the specifications should be tested by an outside testing group, a top-down design should be used whereby there are refinement steps to breakdown large steps of the solution into smaller modules, and structured programming should be used. The cycle of debugging procedures was discussed, going from on-machine debugging with carefully designed debugging procedures to having test cases that are often not carefully planned out but can be run multiple times quickly. The hardest part of building is the system test, which should use debugged components, programs and data built for debugging purposes, someone to control the changes, incremental component adding, and quantized updates.

An example of top-down design. In this case, for writing an introduction. However, the idea can be applied to desigining programs. Source: leo.stcloudstate.edu

Chapter 14 discussed to incident of shifting schedules. There should be a schedule that contains a list of milestones, each with a concrete event and date. to make it easier to stick to the schedule. PERT charts are helpful for keeping track of progress. The fact that the manager is not inclined to let his boss know about the gradual slipping of the schedule was also discussed, and the book suggests that the boss must change his behavior to encourage the managers to keep him updated.

Chapter 15 discussed the user view of the program, and the ways different project documentations must be presented depending on the situation. The book emphasizes that flow charts are only helpful if they are one page, and that they usually are not done until afterward. Finally, self-documenting programs were discussed, whereby the program's documentation occurs within the code itself by use of commenting and proper naming of variables.

Discussion
I especially liked that the book suggested that showing someone how a job is done is much more successful than just telling them how to do it. I also prefer the self-documenting approach to writing tons of unhelpful documentation to accompany the code. I think both of these ideas should be used in future work, to make code easier to read and modify and to show users how to use the program in a proper way. I did, however, think the discussion about managers telling the boss about schedule slips to be a little unrealistic, since many bosses would not be very amenable to hearing that.

The Mythical Man-Month Ch 10-12

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
The need for documents was discussed, presenting the different kinds of documents that are needed for various jobs. These need to answer what, when, how much, where, and who. Generally, these include objectives (defining what needs to be met), specifications (including the manual), schedule, budget (forces decisions to be made), organization chart (describing those working on the project), and space allocations. Formal documentation is necessary to have decisions in writing for easier communication and to give the manager a way to see where he is and changes are needed.

The idea of planning to throw away a system was discussed, since the first system is generally only barely usable. Change must be accepted as a part of building a system, since many things can change, including the user's needs and requirements. As development proceeds, the number of changes necessary increases. To plan for changes, a system must have careful modularization, extensive subroutining, precise and complete definitions of intermodule interfaces, complete documentation, use of a high-level language, and version numbers. There needs to be a proper amount of management control in order to create an organization that allows for change in the program. Program maintenance is necessary once the product has been released, and bugs often reappear in later releases since fixing one defect has a good chance of creating a different one.

The first system should be planned to throw away. Source: blogs.bgsu.edu

Tools are required for creating programming projects, such as a computer facility, operating system, language, utilities, debugging aids, test-case generations, and text-processing system. There should be one toolmaker per team that masters the common tools to explain to others and builds special tools that are necessary. Target machines are those that the software is written for, and require a target facility and scheduling in order to properly test the program. Vehicle machines are those that provide services used in building the system, and require simulators for stability, compiler and assemblers, program libraries, program tools, and a documentation system. Finally, the importance of using a high-level language was discussed, since it increases productivity and debugging speed.



Discussion
I think these chapters presented some very good points about the actual building process of a programming project. Some of the suggestions and comments were outdated and the job hierarchy of managers and such that was constantly being used was a little difficult to understand since I have not had much experience in a work place. This made parts of the chapters confusing, but overall, the points made were useful. The importance of documentation, constantly changing and improving a system, and having the required tools for programming were good points, and I believe these could be applied to future projects to improve them, such as making sure to have structured documentation so that everyone in the group knows what is going on.