Chapter 18 was just a short outline of what the originally published Mythical Man Month had. It went through each chapter and mentioned some of the key points. The final chapter is about why the second Mythical Man Month edition was published. The author speaks about some of the key points that made the book popular and why he thinks it still applies.
These two chapters were not very informative. The author seemed to drown himself in self congratulations while he simultaneously shoved his own work and achievement further down our throats.
Tuesday, April 26, 2011
Monday, April 11, 2011
Mythical Man Month CH 16-17
Chapter 16 talks about how to make the software design process better and about how there is no silver bullet to the troubles of the project. It argues that one of the biggest problems is that many companies seek to build what is already built instead of buying it on the market when they should which would be faster and cheaper. Chapter 17 revisits the paper and the idea that there is no magic bullet. It in fact argues that there might as well be one. Most of this chapter is spent rebutting specific arguments.
I wasn't a fan of these chapters. The papers seemed pretty outdated. The second chapter was really bad in that it was just a rebuttle of many arguments that had been previously made. The problem is that I was never part of the initial discussion so I have little stake in the issue.
I wasn't a fan of these chapters. The papers seemed pretty outdated. The second chapter was really bad in that it was just a rebuttle of many arguments that had been previously made. The problem is that I was never part of the initial discussion so I have little stake in the issue.
Sunday, April 10, 2011
Mythical Man Month CH 13-15
Chapter 13 talks about debugging and how to produce programs that work. It highlights different ways to go about debugging the system as a whole and its individual parts. The next chapter talks about how to deal with schedule slippage and that if the team is able to get ahead then they will have some cushion in case of an emergency. The final chapter of this excerpt focuses on how to write good documentation with the author "showing" the reader how to write good documentation.
The second chapter of the excerpt, chapter 14, was really weird to me because it seemed to contradict the rest of the book. For the entire book the authors had argued for the reader to make tight schedules that have no cushion but in this chapter, they argue that the team should work really hard to form a cushion. So the question is what do they want, a looser schedule with cushion or a tight schedule with a team that is dying trying to get ahead.
The second chapter of the excerpt, chapter 14, was really weird to me because it seemed to contradict the rest of the book. For the entire book the authors had argued for the reader to make tight schedules that have no cushion but in this chapter, they argue that the team should work really hard to form a cushion. So the question is what do they want, a looser schedule with cushion or a tight schedule with a team that is dying trying to get ahead.
Mythical Man Month CH 10-12
Chapter 10 discusses different types of paperwork and attempts to affirm their validity and necessity. The next chapter goes in direct opposition to the XP book and talks about being ready to throw one version away, labeled a lesson learning endeavor and to plan for change in the project. Chapter 12 talks about the tools that programmers and programming projects have and the differences between community tools and individual tools that the programmers don't share.
I liked the discussion about the tools. I have seen many senior programmers that have their own small utilities that help them immensely. I feel that I do this myself to a degree as compared to freshmen computer science students. The idea that the best tool is communication and that the individual tools hamper communication was an interesting one.
I liked the discussion about the tools. I have seen many senior programmers that have their own small utilities that help them immensely. I feel that I do this myself to a degree as compared to freshmen computer science students. The idea that the best tool is communication and that the individual tools hamper communication was an interesting one.
Subscribe to:
Comments (Atom)