The Mythical Man-Month Ch 18 - 19

Summary

Chapter 18 – Propositions of The Mythical Man-Month: True or False? – This chapter is a summary of the entire book, chapter by chapter. It outlines the most important points from each chapter and what they mean.

Chapter 19 – The mythical Man-Month after 20 Years – This chapter discusses why the second edition of the book was made and what still remains unchanged and current from that version and what does not. The author explains how conceptual integrity is still central in both books. Also, he talks about how WIMP (Windows, Icons, Menus, Pointing interface) in his opinion will be obsolete in a generation. He also explains why the waterfall model is wrong and why we should not use it. At the end, he discusses the importance of a good team, what technology has achieved and its effect, and what he expects of the future.

Discussion

I really liked chapter 18 as it encompasses most of the important points discussed throughout the book. It is a good summary and it refreshed my memory on what I have learned throughout the semester. Chapter 19 was also very interesting as he goes back into the book and updates the reader on the things that are now outdated and the things that are still relevant. Some of the things he said, however, made some of the chapters seem pointless to read. In any case, it definitely doesn’t hurt to know all these things. It was a good book!

The Mythical Man-Month Ch 16 - 17

Summary

Chapter 16 – No Silver Bullet – Essence and Accident in Software Engineering – In this chapter the author divides the difficulties in software development between essence and accidents. Essence describe the difficulties inherent in the nature of software; while accidents describe those difficulties that today attend its production but that are not inherent. He explains that in the next decade there will be no major technological or managerial development that will improve our productivity by one order of magnitude. The chapter describes how little has been done over the years to improve how we carry on the essential tasks so even with all the technological advances our productive has not yet improved by an order of magnitude because they have only addressed the accidental part of the equation.

Chapter 17 – “No Silver Bullet” Refired – the chapter divides the essence into four subcategories: complexity, conformity, changeability, and invisibility. Complexity refers to how no two parts of software entities are alike and how they have a huge number of states. Moreover, as the size of the system increases, its parts increase exponentially, and you can’t abstract away the complexity. Conformity refers to the arbitrary sets of rules and changes software has to go through. Changeability refers to how software is constantly asked to change. Finally, invisibility refers to how software is invisible and unvisualizable in contrast to other more tangible things and this lack of visualization deprives the engineer from using the brain’s powerful visual skills.  In this chapter the author reflects on a paper he wrote ten years before and clarifies certain misunderstandings. At the end he quotes what someone wrote about his paper that summarizes what he wants to say: “Software development is a conceptually tough business. Magic solutions are not just around the corner. It is the time for the practitioner to examine evolutionary improvements rather than to wait-or hope- for revolutionary ones.

Discussion

I agree with most of the things he says in Chapter 16. However, I believe we have improved a lot in meeting customer needs and this in turn has helped improve productivity. Probably not a lot compared to how much more productive these methods should have become. In any case, he is right about how tough of a business is software development and how we should be examining evolutionary improvements. 

The Mythical Man-Month Ch 13 - 15

Summary

Chapter 13 – The Whole and The Parts – this chapter is about integration of system component and how hard this can be. The chapter explains several methodologies we can follow to make the process easier. It talks about top-down design and how this type of design can avoid bugs. Also, time-shared debugging and system debugging can make the process much easier.

Chapter 14 – Hatching a Catastrophe – this chapter is about the importance of concrete milestones in the development of software to avoid major problems. The chapter discusses how essential is to have a schedule and to keep pert charts updated. Also, managers must reduce role conflict in order to get accurate information from their employees and avoid future disasters.

Chapter 15 – The Other Face – this chapter is about documentation and its importance. Different levels of documentation are required for different users and the programmers who write the documentation must understand that. The chapter also talks about flow-charts and how they are not as useful as they seem to be. One last thing the chapter talks about is self-documentation. Programs should be easy to read and understand without the need to understand every line of code.

Discussion

I enjoyed chapter 14 because it talks about the importance of communication in teams. We can see how bad communication can affect a project outcome all the time. If the manager of a project is open, not giving orders all the time, and easily approachable then the project will be much more successful. I think this is a really key point in project development. Also, I found really interesting how the book downplays the function of flow-charts in projects. I mostly agree with the book but I do believe they can also be useful, it all depends on how you develop them and for what do you use it for.

The Mythical Man-Month Ch 10 - 12

Summary

Chapter 10 - The Documentary Hypothesis – the chapter discusses the importance of having and maintaining formal documents when dealing with a software project. There are several reasons why doing this is important. First, writing decisions down is essential as it solidifies them and makes them clearer. Second, the documents will communicate the decisions to others that migh not know them yet. Finally, a manager’s documents give him a database and checklist.

 

Chapter 11 – Plant to Throw One Away – this chapter is about change and how we should plan for it. We should know that the system and the organization will change. The system will change as we realize not everything is going to work as we expected it. The management structure will change as the system changes, and we must be preared for it. Also, even after the program is delivered to customers, changes will continue to happen (program maintenance).

Chapter 12 – Sharp Tools – this chapter is about the tools used in a project. The essential tools are a computer facility, an operating system, a language, utilities, debugging aids, test-case generators, and a text processing system. The chapter then goes on and explains each of those tools.

Discussion

These three chapters address really important topics. First, keeping formal documents of what is done and what decisions get made is a very key part of any project. Second, system and organizational change is obviously happening and encouraging people to accept this is really important. I thought it was really interesting that the book says that programs will be at their best at the beginning (by their first release). You would logically think that the more errors you fix and the more iterations you release the better the system would get, but I guess is just a misconception. Finally, choosing the right tools is a critical part of a project, and the chapters hits on every single key part.