Book Reading #22: The Mythical Man Month

The Mythical Man Month
Dr. Brooks
Addison Wesley Longman Inc.

Chapters 16&17:

These chapters both focus on the same topic, and that is, there is no silver bullet in programming. Essentially it is the idea that once the software becomes a large uncontrollable beast that it cannot be stopped. We all want to be able to shoot the program with the silver bullet and be able to reduce its time and costs and just have it be dead and done with. To accomplish this, programmers need to realize that they need to look at design elements such as conformity, changeability, invisibility and conformity and make them play off each other equally. This also takes the cooperation of a team and making sure that each player on the team understands what needs to be done as well as where the project is going. The team needs to have a unified programming environment and cooperating standards of coding to accomplish the task. The team needs to also be able to set themselves up into stations, similar to the idea of the surgical team each person needs to have a job and they need to be able to do it at all times. This makes the group flow together and they allow the group to make lots of prototypes and develop in ways that are doable by the programmers but also comfortable to not make mistakes. The whole team needs to have clearly defined roles and each person needs to make sure they have a mentor or someone who they can fall back on in times of need. However, there is some things that can be done to a project that can help it immediately, without being the great "order of magnitude" jump that programmers are looking for. Ideas such as designing the interface with the customer in mind and doing things that the customer said they would like to see in the software is a pure bona-fied way to get more sales as you are adding features that the users said they would directly pay for. There is also the idea of having "interchangeable methods" that is, methods that only do actions with the information they are given and do not affect the program as a whole, this way if a method becomes hopeless or done then it can simply be removed or fixed later. They also talk about the idea of the brass bullet and will it do when you cant find a silver bullet? Can you simply fix a lot of small things and make the program into a working piece of software that maybe has a few flaws that are livable? This essentially comes down to the idea of reusing what you can and doing cost-benefit analysis of what needs to be done and what can be left for a later version or an upgrade. Essentially it is the idea that while you might not be able to do a single change that will improve your program ten fold, you can fix enough to make it good software, you just need to know where to look.

I like these paragraphs for the most part but there seems to be examples missing here. I get what they are saying and I understand the chapters but I don't see any examples or what kinds of situations you want to practically apply these. In most of the chapters there are lots of good examples and there are specific historical and personal cases of the author using these and it really feels like he defends his work and says WHY these techniques work. In this case, he presents these two conflicting viewpoints and then simply says "these are the cases, they work like this" and doesn't really back up his claims. I feel like even if he didn't want to be objective and say strait out "I support this side of the argument" and then write more about that one that would be fine but we don't even get that. It feels like we are trying to fit into a small pair of jeans and we know we can simply cut off the knees and be OK. Why not just simply give a basic example and say that's good enough, why try to make these chapters so overly involved with technical. In fact these are some of the longer chapters and they really don't say much that hasn't already been said in earlier chapters of the book. I think that the ideas are really good but if you used some of the techniques presented earlier in the book then you wouldn't even be in this situation. I liked these chapters but wanted more examples.

Book Reading #21: The Mythical Man Month

The Mythical Man Month
Dr. Brooks
Addison Wesley Longman Inc.

Chapters 13-15:


In these chapters we find out about some of the more technical aspects of design and why they are important to us as computer scientists. The first part is about the whole and its parts and how any man can write any program it is based on if you do it correctly. The chapter then almost goes into a brief overview of everything we read about in Xtreme Programming Installed such as bug proofing programs, testing all the parts, top down design and the like. It did not go into the specifics on how to do this but rather overviews of each of the parts and why they are important. The latter half of the chapter was almost completely about debugging from figuring out what component and system bugs are and how to handle them both, to figuring out test cases for the two and determining patterns on how to solve them to important aspects of design such as paying attention to one component at a time. There was a bit at the end about quantizing data that was confusing. The next chapter was about hatching catastrophe and the steps that need to be taken in order to prevent a large error in your programming. The interesting part of this is that the first solution presented is to make milestones and not millstones, that is, if something is taking too long it is likely that it is not being done correctly or is being designed in such a way that there is going to be a lot of bugs in the software. In general, software should be relatively simple and anyone should be able to recreate what you did if given the time and the people. Software that isn't properly designed will just make the lives of those who need to use it later harder and likely they will spend more time figuring out what was done rather than how to fix it. They also talk about how you cant brush problems under the rug and this usually results from the conflict of roles in the office place. They say that management needs to be willing to yank the rug out and find out what is going wrong with something if an issue surfaces. The last chapter talks mainly about documentation and why it is required and important for every program that you write. There is a list of 10 things that are given to tell why it is important and why it is needed for each program. The author also actually says that flow charts are a bit of a curse and can at times be misleading. He rather says that you should have code that is very self-documentable and this should make the process much easier on you and the people who will use your software later. In all the chapters covered some of the rather difficult parts of design and let the reader know some simple things on how to prevent them.

The chapters were actually rather interesting and what I find more interesting is despite the amount of information that was said it was a relatively quick read. I think my favorite part was about hatching a catastrophe as just the initial setup of a program or the way something is defined can set it up for failure. If one tries to make one large code segment that does a very complex operation that can only be seen by the person who wrote it then likely that design needs to be broken into smaller parts and those parts need to be tested. I am a large advocate of writing small tests and making sure that all work mostly because that is what I am going to be doing at my job at Halliburton later this year but also because I have written many programs in academia and I have never had sufficient time to write small iterations and tests that I know would have been beneficial to the programs success. This leads into the next part of the text which talked about documentation and I believe if I had time to write these small tests that I would likely be able to site my documentation really easily instead of, basically, having one person from the group do the dirty work and write the documentation on his/her own. I think that the part on the whole and its parts were good and it did talk about debugging which goes hand in hand with testing but I feel like this was more of a recap of the Agile stuff that we have all learned. It seemed like the same lecture over again, program in pairs, test to find bugs, make user stories, make them small and estimate their time etc. I feel like this might only be so because I have had A LOT of readings this semester and a few of them have been similar. Despite this this was really one of my favorite set of chapters and I can only hope that the next chapters will be as informative as these were.

Results for Week[9]

We are still testing a lot.

Here is essentially what we want the tests to be:

<video removed>


And here is the shirt in covert action:

and here is lab sillyness:

Book reading #20: The Mythical Man-Month

The Mythical Man-Month
Dr. Brooks
Addison Wesley Longman Inc.


Chapters 10-12:


In these chapters we find out about some of the more design aspects of computer science, namely the thinsg that happen before youe ver wrire andy code. Specifically it talks about items such as system design documents, system specs, how you should be willing to throw stuff away and the tools you can use to make these better. The first chapter talks about the hypothesis that comes with designing documents and the various features that they have. Specifically its talks about different kinds of documents for different products. Clearly based on what you are designing you need different kinds of specifications based on computer size, data, budget and other factors once we have considered all of these things can we decide what specs we need for the system and iron all the details out. One of the most important thing to remember is that the reason we do documents in the first place is to make sure that everyone is on the same page and that there is no excuse for what work is to be done. It gives everyone a way to make sure that everything is done and documented. The next chapter talks about one of the most useful tools in document design and that is the idea of being willing to throw one away. The author wants to make sure you remember that the only thing in the world that is consistent is inconsistency and you need to be ready to do things different than planned. This simply drives home the idea of make two and be willing to throw one away, or if you can't be willing to throw away your first one.The problem with this is that even if you adjust and make a really good document you sometimes each time you fix a bug you are simply taking two steps forward and one step back as fixing one bug could cause new ones to surface. There will never be a perfect document but there will be a program that will be acceptable for the average user and the best you can do is keep the documentation and try to improve on it. Chapter 12 talks about sharp tools and the things we can do to make documents better. One of these is making sure you have a target, and making sure that everything you do towards the project is in line with that goal. They then go into some good discussion on high level language and how interactive programming can make this process better and smoother. The worst thing that can happen is when someone goes off and sits in their cube and codes without any interaction, the product may work but it will not be the best it can.

These chapters were actually really helpful the different ideas that were presented in this chapter were actually really helpful and they are things I can see myself having to look at in a few months with a job coming up. Documents can be very important and the time spent into them is all to keep people on track. IF you want to get code written in any reaonable amoutn of time you need to have your group organized and make sure everyone is working on something different and that two people aren;t working on the same thing. IT also helps if you do have a plan that is quire felxable and that is probably my favoire thing about these chapters is the idea of being willing to throw one away. I think that this is important because it goes beyond just coding documents it also speaks to papers in school, memos, emails and a lot of other things that need to be written and need to be flexible in case things don't work out. We have all also heard of the cs joke the last bug and this chapter basically says that is indeed true. You even might try to fix a bug and make two more so it is a vicious cycle if not done correctly. I didn't quite get the chapter about tools and really think it needed more substance and more practical examples of these tools. I think the author did a good job of describing them but it didn't really get what they were supposed to do. I think that these chapters were rather informative and that some of the examples were really good but they were sparse in places. The most interesting thing about these is that the more chapters I read the better I am starting to understand where the book is going. The lessons are really starting to make sense and the material is very relevant to me.