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.  

The Mythical Man-Month Ch 7 - 9

Summary

Chapter 7 – Why did the Tower of Babel fail? – This chapter discusses the importance of communication in a project. Teams should communicate in as many ways as possible; including informally, by meetings, and through a workbook. The project workbook refers to the conglomeration of all the documents produced by all the teams working in the project, including objectives, specifications, standards, etc.  The workbook should be in a direct-access file that every programmer should be able to access and modify.

Chapter 8 – Calling the Shot – this chapter is about programmer’s productivity. The chapter explains several results from different researches on the difference between how long a task actually takes and how long the programmers predict it will take. For some reason, completing a task always seems to take longer than expected.  Mainly because of other factors that programmers don’t take into account when predicting; like sickness, days off, personal time, paperwork, meetings, etc.

Chapter 9 – Ten Pounds in a Five-Pound Sack – this chapter is about the size of programs and its importance. Size needs to be controlled by defining exactly what a module must do when you specify how big it must be. Also, the entire team must work together for that to happen- by thinking about the overall program and not only the piece you are working on.

Discussion

The chapters were interesting, especially Chapter 8. I think it talks about a common problem that all programmers seem to encounter at some point or another. We always predict things will take a shorter amount of time that what they actually do. I think in order to correct this error we should always expect problems along the way. Also, Chapter 7 talked about a really important concept: communication. The idea of having a workbook is really smart and seems applicable to any project, regardless of how small or big.

The Inmates are Running the Asylum Ch 3-5

Summary

Chapter 3 – Wasting Money – This chapter discusses deadline management. A lot of projects are just rushed out the door, and most times this is not the best idea. Is better to have a good program in 6 months than a bad program in 3.  The chapter talks about several points. First, in order to be able to ship a product and ship it right we first must know what “done” looks like; this means we should know from the beginning what exactly do we want t ship and how do we want it to look. Second, we should understand that shipping late is not the end of the world. Third, feature lists are not problem solving tools; as in fact more features doesn’t translate into a better program. Finally, we must understand the actual costs of bad software, including the money spent on technical support. In summary, we should not define the boundaries of a development project only in terms of deadlines and feature lists.

Chapter 4 – The Dancing Bear – the chapters describes what bad software really means. The first problem is that people don’t really realize that they are utilizing bad software; they think that if it gets the job done then is good enough. However, most of these products don’t make the user happy or even more effective. The chapter then goes on and explains how simple products like email programs, scheduling programs, and calendar software fail. So what is wrong with software? According to the chapter it forgets, is lazy, is parsimonious with information, is inflexible, it blames users, and it won’t take responsibility.

Chapter 5 – Customer Disloyalty – this chapter discusses the importance of customer loyalty and how it is achieve. Design is an incredible important part of the process, as it turns a product that can be built and performs well (engineering capability), and that can be distributed and sold profitably (business capability), into something that people really want (design capability.) Based on this, design will get you customer loyalty… and customer loyalty will bring success to a company.

Discussion

I really like all the examples that the book uses as that way it is much easier to understand what they mean. I think it is interesting how in all these book the “feature” problem keeps reappearing. Apparently, it is obvious to everybody except the programmers that are building the software. Also, the importance of customer loyalty is truly remarkable and obvious in today’s market. There are tons of products out there with practically the same exact set of functions and features. However, customer loyalty could make one product successful while all the others fail.

The Mythical Man-Month Ch 4 - 6

Summary

Chapter 4 – Aristocracy, Democracy, and System Design – This chapter is about the importance of conceptual integrity, which means that a system reflects one set of design ideas, instead of many uncoordinated ideas. We tend to think more features is better, but in reality that does not help achieve conceptual integrity as it actually makes the system harder and more complicated to use. Ease of use, then, dictates unity of design. Another problem with achieving this is the fact that systems are built my many people, and in turn many heads that think differently. Separating architecture from implementation or using the structuring programming implementation of teams talked in the last chapter can resolve this.

Chapter 5 – The Second-System Effect – this chapter is about the tendency of small, elegant, and successful systems to have bad systems as their successors. The chapter gives several examples of this. The best way to avoid the second-system effect is to be aware that it exists and pay extra attention when developing the second system.

Chapter 6 – Passing the Word – this chapter is about teamwork and how to make sure everyone is on the same page when working on a project together. There are several ways of making this happen. First, have very specific and precise written specifications about the system. Second, require the implementation to include a macro. Third, meet face-to-face with the team a lot. Fourth, understand and accept that there should be more than one implementation of the system. Fifth, keep a telephone log of the team calls and questions. Lastly, test your product a lot!

Discussion

I think it is interesting how all the books we are reading overlap at some point. Chapter 6 of this book talks about teamwork and Chapter 4 about the importance of design as a whole. The chapters have the same ideas as the other books, which I agree with. Mainly that system should be easy to use and have an overall design and idea. Also, teamwork is obviously one of the most important parts of developing a system and it must be monitored closely.