Dr. Brooks
Addison Wesley Longman Inc.
Chapters 7-9:
In these chapters we find out about more interesting designs and concepts in the world of computer science production. In these chapters we cover how distastes can happen looking at the Babel Tower case. We learn about taking actions and making a choice, and also how we, as compute scientists, try to fit ten pounds of stuff into a five pound bag. The Babel Tower case was a disaster and the strange thing was that they had all the technology that was needed to do it, they had adequate time and funding, they had a good design so what could have possibly gone wrong? Well, apparently there was a lot of communication breakdown that all eventually lead to the end result of having a twisted heap of stone and wire on the ground. Essentially there were too many people trying to hold too many jobs and not enough ideas about the project or changes or information was being passed among the workers on the Tower. In fact the boss was being handed a new list of changes each day and he and his team would spend hours trying to figure them out only to have them completely changed and redone the next week. They also have a story about an engineer who is pushed so much that he is unable to do his actual job of being the construction engineer and needs to be helped a little bit. Essentially even if you have a good project you need to be able to adequately show changes and make sure that all the people who are involved and looking at the high level are easily able to understand them. In chapter 8 we are told to learn how to call the shot, and this involved making sure you know what is going on and then being able to decide what you want to base your calling on. Four examples are given and each highlight a different way of gathering and displaying data with the end result being that they were able to assist the person in getting to a decision but the overall effect was in most cases the same, making the decision. Finally we look at constraints that computer scientists run into, specifically we look at cases where the computer scientist tries to do too much with too little. Essentially each system has a set of constraints and part of the job of the designer is to try to work with these constraints and make sure that everyone understands what they are and how the group wants to work around them. There are size constraints, resource constraints and even constraints on how different things can be represented. They key is to make sure that everyone understands them and then when a solution is devised that everyone sticks with the plan and no one tries to become an island. There a few situations discussed here but overall driving home the idea of not trying to do too much with your limited time.
I thought these chapters were interesting enough. I think the part I liked the most was the engineer who got a couch in his office, I want a couch to relax on. It does speak to the point of understanding your space and being able to communicate things effectively so that no one person is trying to do too much. I also think that it is interesting on how the author talked about a situation where all the constraints were satisfied and still the project went wrong despite all these things. It seemed like he was trying to speak to the notion of this project would have gone much better if someone had only used the techniques from the next chapter and really just made a decision and ten made everyone cooperate. I also believe that a lot of the things brought up in the Babel case were classing computer scientists thinking that something is going to work and not really having the evidence or experience to be 100% confident. This kind of leads into the third chapter (chapter 9) that talks about how we have a tendency to do too much. What I find the most interesting is how the author does talk a lot about how there can be too many features in something but doesn't really go into the idea that as computer scientists we are very into processes and sometimes we can spend so much time arguing about the process that we forget to actually figure out how to design the system. I think there are a million more topics I could go on about with this but I think these chapters simply made me understand a few basic things: 1. don't try to do too much to any given project, follow the KISS principal. 2. If you are faced with a decision, gets as much information as you can and then make a call. 3. finally, if you are making changes, make sure they're clear and concise and report them to all the people who need to know about them.
No comments:
Post a Comment