We got the whole system together!! Woo!
Project over!
J/k but we did get a working model:
I know the video isn't quite a minute but its pretty close.
Things to work on for next week:
More stable construction for futher user testing
Application integration with GeoTrooper
Testing on person with battery pack.
More tests of user feedback.
Thursday, March 31, 2011
Tuesday, March 29, 2011
Book Reading #19: The Mythical Man-Month
The Mythical Man-Month
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.
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.
Thursday, March 24, 2011
Report on Weeks 6-7
Got quite a bit done!
Looking at in class presentation!!
Accomplished:
Got concept of shirt completed, can be done with thread.
Got blue tooth working.
Testing power supply.
Tested shirt for shocks and user wear ability.
Updated Aurdrino to being listening for blue tooth.
Wrote simple android app to test.
Looking at in class presentation!!
Accomplished:
Got concept of shirt completed, can be done with thread.
Got blue tooth working.
Testing power supply.
Tested shirt for shocks and user wear ability.
Updated Aurdrino to being listening for blue tooth.
Wrote simple android app to test.
Saturday, March 19, 2011
Book Reading #18: The Inmates are Running the Asylum
The Inmates are Running the Asylum
Alan Cooper
Sams Publishing
Chapters 3-5:
In chapter three we look at the idea of deadlines and how they are managed. In fact we learn that deadlines can sometimes be the ultimate factor that can kill a program and that more programs have died because of going out too early than have for not finishing features or not having an interface completely fleshed out. Cooper really talks about what done should look like and the idea that shipping something late is not the end of the world. In fact he actually sometimes encourages this just to make sure that the program is not rejected and the idea that if a completing product turned out then even if you quickly release another version then people might not come back to your product or try it again. He also stresses the idea that if you have a feature that is not completed it is probably better to leave it out then hastily shove it into a program and have it messing up different things that people work on. In fact sometimes having too many features that are only slightly buggy can be a lot worse than not having the feature and the user requesting it and then releasing it in a later version. In this way it also seems like the company is listening to the user and building their product to better suit them. In chapter 4 Cooper talks about the rather humorous notion of the Dancing Bear, that is, technology that doesn't work no matter how many versions of it there is and who designs it. He gives the mother of all examples and talks about VCR's and how it was impossible to tell what they were doing and despite companies trying to make them better and easier to use they were still nearly impossible to navigate and lots of money was wasted on trying to find ones that were intuitive and practical. He expands these ideas to the idea of email and calendar software and how their simple features that were probably not even considered to be bad simply go overlooked and end up becoming dancing bears of the program. Last he talks about the idea of customer disloyalty and how a product or program becomes desirable to the masses. He references chapter three a lot and talks about how these kinds of plans and features carry over to the idea of desirability and how time to market plays an important role but also that comparison is equally important. Simply put, if you have a similar product that takes longer to market and is more expensive it doesn't matter that you have feature X most people will not switch or even try. Same thing with releases each needs to be good to prevent disloyalty.
This is quickly becoming one of my favorite books, while it is a little longer and in some cases the examples seem to go on for forever there is some really good knowledge and the ideas that are being pushed forward are very solid and I can really relate to them. The idea of the dancing bear is really very smart and the fact that this happens a lot with products is really something that computer scientists need to watch out for and prevent. It also seems like this book is doing a rather good job of supporting ideas that were talked about in the Extreme Programming book in that programming in groups and making sure you make stories that the user will understand as a way to design a product is important. I think also that the fact that he head on tells you that some things will be wasting money is a really good idea. Simply put, if you try to do too much and rush out a program it really is going to be wasting more money than letting the project go for a bit longer and then having a good release, or even scrapping the project and cutting your losses and then putting those people on a new project or on other project, both of which have costs but in the end might help save you money. The bets chapter here is the one about disloyalty, what it means and how it is gained through comparison and markets. It is the idea that you need to have a good product every time all the time and that if your product fails even once it could possibly cause disloyalty and make the product seem inferior. I think this is very true and similar to the movie The Social Network, while the movie was overall not *great* one of the big things Zuckerberg pushed was the idea that the site cannot go down, otherwise it will become an afterthought. I liked these chapters a lot and really don't think I will mind reading this book if the chapters continue in this manner.
Alan Cooper
Sams Publishing
Chapters 3-5:
In chapter three we look at the idea of deadlines and how they are managed. In fact we learn that deadlines can sometimes be the ultimate factor that can kill a program and that more programs have died because of going out too early than have for not finishing features or not having an interface completely fleshed out. Cooper really talks about what done should look like and the idea that shipping something late is not the end of the world. In fact he actually sometimes encourages this just to make sure that the program is not rejected and the idea that if a completing product turned out then even if you quickly release another version then people might not come back to your product or try it again. He also stresses the idea that if you have a feature that is not completed it is probably better to leave it out then hastily shove it into a program and have it messing up different things that people work on. In fact sometimes having too many features that are only slightly buggy can be a lot worse than not having the feature and the user requesting it and then releasing it in a later version. In this way it also seems like the company is listening to the user and building their product to better suit them. In chapter 4 Cooper talks about the rather humorous notion of the Dancing Bear, that is, technology that doesn't work no matter how many versions of it there is and who designs it. He gives the mother of all examples and talks about VCR's and how it was impossible to tell what they were doing and despite companies trying to make them better and easier to use they were still nearly impossible to navigate and lots of money was wasted on trying to find ones that were intuitive and practical. He expands these ideas to the idea of email and calendar software and how their simple features that were probably not even considered to be bad simply go overlooked and end up becoming dancing bears of the program. Last he talks about the idea of customer disloyalty and how a product or program becomes desirable to the masses. He references chapter three a lot and talks about how these kinds of plans and features carry over to the idea of desirability and how time to market plays an important role but also that comparison is equally important. Simply put, if you have a similar product that takes longer to market and is more expensive it doesn't matter that you have feature X most people will not switch or even try. Same thing with releases each needs to be good to prevent disloyalty.
This is quickly becoming one of my favorite books, while it is a little longer and in some cases the examples seem to go on for forever there is some really good knowledge and the ideas that are being pushed forward are very solid and I can really relate to them. The idea of the dancing bear is really very smart and the fact that this happens a lot with products is really something that computer scientists need to watch out for and prevent. It also seems like this book is doing a rather good job of supporting ideas that were talked about in the Extreme Programming book in that programming in groups and making sure you make stories that the user will understand as a way to design a product is important. I think also that the fact that he head on tells you that some things will be wasting money is a really good idea. Simply put, if you try to do too much and rush out a program it really is going to be wasting more money than letting the project go for a bit longer and then having a good release, or even scrapping the project and cutting your losses and then putting those people on a new project or on other project, both of which have costs but in the end might help save you money. The bets chapter here is the one about disloyalty, what it means and how it is gained through comparison and markets. It is the idea that you need to have a good product every time all the time and that if your product fails even once it could possibly cause disloyalty and make the product seem inferior. I think this is very true and similar to the movie The Social Network, while the movie was overall not *great* one of the big things Zuckerberg pushed was the idea that the site cannot go down, otherwise it will become an afterthought. I liked these chapters a lot and really don't think I will mind reading this book if the chapters continue in this manner.
Book Reading #17: The Mythical Man-Month
The Mythical Man-Month
Dr. Brooks
Addison Wesley Longman Inc.
Chapter 4-6:
In these chapters we are exposed to more ideas about what happens with programming and how different kinds of phenomena can affect a program. The first one we look at is the idea of different political systems in program design. This is simply the idea that sometimes when a program is written there are some things that try to be improved and implemented but because of the aristocracy of program design conceptual integrity is pushed to the wayside and not really able to be maintained. In fact there are a lot of times that a program needs to be worked on more and there is a constant back and forth between the programmers and the program leaders, pointing fingers and one side saying that the other is doing them wrong. This leads us into what Brooks calls the second system effect which is the idea that the second time a program is written it sometimes needs to be improved and sometimes this doesn't happen because of the discipline of the team or the programmer. Simply put, the second time a program is written it doesn't need to be a rehashing of the first program using its based code and building on it, it can be a whole new idea and the best way to do this is by having a large amount of self-discipline while programming. These are practices that the programmer wants to watch but in some cases because of not following self-discipline these ideas can get out of control and the programmer will try to do too much and have the second version nor working nearly as well as the first. Again the programmer is encouraged to make the second version new and better but needs to be sure to keep it in the realm of doable and not overextend and try to do things that will not benefit the program and make it take longer to produce. Last is what Brooks calls "Passing the Word", that is, the idea of how a program is described from management to programmers and the various techniques that do and don't work. He discusses the difference between the manual, definitions, incorporation and various other means. He explored the use of multiple implementations, logs and product testing as ways to make sure that the program goes out. While each of these has strengths the programmer needs to remember what is important and be sure that he works with management and that each task is clear. Although each of these various ways to define and test a program have their merits, companies need to carefully evaluate each and if one fails not be afraid to try another.
This picture warrants an explanation. I took from him that bad managers can be snooty and high strung, kind of like the aristocrats pictured here.
These chapters were very interesting but in some cases lacked the information that I thought would be necessary to understand these. For example in the last chapter the author talks about formal definitions for three pages and really spills out what it means and how the various features work, but then only gives a paragraph on direct incorporation and almost challenges the reader to look up the rest of their own. I really felt that this would be something to consider but it was as if he was trying to push the ideas of doing manuals or definitions. Also the chapters on aristocracy seemed really informative and if I was a manager I would really want to understand the psychology between these groups then this is the kind of information I am looking for, however, it did seem like the two sides really bicker a lot and he just talks about the situation and really kind of brushes over solutions. I can tell that Dr. Brooks has a lot of experience and is really smart and his chapters are really interesting to read but sometimes I am wanting a practical example or a solution and he really just gives incite and not a lot on WHAT to do or HOW to do it. I would think knowing that he is writing this for computer scientists and knowing how into processes we are that he would think to give some examples and how he changed them even if the changes were on a case by case basis. The most interesting part of this was definitely the second system effect and the phenomena that surrounds it. That kind of information will really stick with me and he even gave a small example of how he insulted Microsoft but ultimately was able to make them a really good product. It was well done and I wished that he wrote all his chapters in that style and it is an idea that will definitely stick with me in my professional career.
Dr. Brooks
Addison Wesley Longman Inc.
Chapter 4-6:
In these chapters we are exposed to more ideas about what happens with programming and how different kinds of phenomena can affect a program. The first one we look at is the idea of different political systems in program design. This is simply the idea that sometimes when a program is written there are some things that try to be improved and implemented but because of the aristocracy of program design conceptual integrity is pushed to the wayside and not really able to be maintained. In fact there are a lot of times that a program needs to be worked on more and there is a constant back and forth between the programmers and the program leaders, pointing fingers and one side saying that the other is doing them wrong. This leads us into what Brooks calls the second system effect which is the idea that the second time a program is written it sometimes needs to be improved and sometimes this doesn't happen because of the discipline of the team or the programmer. Simply put, the second time a program is written it doesn't need to be a rehashing of the first program using its based code and building on it, it can be a whole new idea and the best way to do this is by having a large amount of self-discipline while programming. These are practices that the programmer wants to watch but in some cases because of not following self-discipline these ideas can get out of control and the programmer will try to do too much and have the second version nor working nearly as well as the first. Again the programmer is encouraged to make the second version new and better but needs to be sure to keep it in the realm of doable and not overextend and try to do things that will not benefit the program and make it take longer to produce. Last is what Brooks calls "Passing the Word", that is, the idea of how a program is described from management to programmers and the various techniques that do and don't work. He discusses the difference between the manual, definitions, incorporation and various other means. He explored the use of multiple implementations, logs and product testing as ways to make sure that the program goes out. While each of these has strengths the programmer needs to remember what is important and be sure that he works with management and that each task is clear. Although each of these various ways to define and test a program have their merits, companies need to carefully evaluate each and if one fails not be afraid to try another.
These chapters were very interesting but in some cases lacked the information that I thought would be necessary to understand these. For example in the last chapter the author talks about formal definitions for three pages and really spills out what it means and how the various features work, but then only gives a paragraph on direct incorporation and almost challenges the reader to look up the rest of their own. I really felt that this would be something to consider but it was as if he was trying to push the ideas of doing manuals or definitions. Also the chapters on aristocracy seemed really informative and if I was a manager I would really want to understand the psychology between these groups then this is the kind of information I am looking for, however, it did seem like the two sides really bicker a lot and he just talks about the situation and really kind of brushes over solutions. I can tell that Dr. Brooks has a lot of experience and is really smart and his chapters are really interesting to read but sometimes I am wanting a practical example or a solution and he really just gives incite and not a lot on WHAT to do or HOW to do it. I would think knowing that he is writing this for computer scientists and knowing how into processes we are that he would think to give some examples and how he changed them even if the changes were on a case by case basis. The most interesting part of this was definitely the second system effect and the phenomena that surrounds it. That kind of information will really stick with me and he even gave a small example of how he insulted Microsoft but ultimately was able to make them a really good product. It was well done and I wished that he wrote all his chapters in that style and it is an idea that will definitely stick with me in my professional career.
Book Reading #16: Extreme Programming Installed
Book Reading #16: Extreme Programming Installed
Extreme Programming Installed
Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley
Chapters 22-24:
In these chapters we effectively finish the book, only do find that there are extra bonus chapters that are simply supplements to the important foundations of the book. However before the book ends we do find out about one taboo in extreme programming and that is the idea of defects...or is it bugs....nope we are not allowed to say bugs! In fact the chapter stresses that we need to not call defects in our code bugs one because of the implication that it is a problem that is going to be persistent and two because it honestly scares the customers and we don't want to do that. There are many ways to handle these and of course the foremost among them is making tests for everything and making sure your tests work before adding your code to the program. Ironically enough this is where a lot of the major bu...I mean defects happen is in testing. However this is not to say that one should not test because testing is very important but you need to make sure to handle defects as they come and stay on top of them. The most important practice in extreme programming is having a plan and sticking to it and if you deviate from the plan there are multiple redundant checks to get you back on course. The conclusion of the book are actual testimonies of companies and groups who have used extreme programming and how much more they really enjoy it than their standard practices. Some groups have found a whole new way to run their business and deliver code thanks to extreme programming. They put a lot of emphasis and really reading the text and essentially making sure you follow the 8 basics of the system:
-On site Customers
-Small Releases
-Planning Based on Stories
-Programming Based on Metaphor
-Pair Programming
-Continuous Integration
-Testing
-Forty Hour Work Week
Keeping these and some other details in mind makes sure that the system effecitvely works and make sure that your team is going to get done what it needs to get done. Finally the last part of these chapters is a suppliment talking about stories and keeping to a track called "We'll try" it is the idea that every programmer has spoken these words and in some cases it can mean the end of the program before it even starts. In fact most people will give up on a program when they think that there is a task that they cannot estimate and this ultimately causes the program to fail. This is not the case and in fact some of these things really are as easy to implement as they make them sound like in the book. Sometimes it may be hard to get a start on them but ultimately they are fairly simple and they just need to be followed and practiced.
I think these chapters in the books were almost eye opening in that people think these kinds of things are rather difficult to do when really they are quite simple. I think the most interesting part of this was when they actually had testimonials of different groups talking about how they were able to implement these kinds of things and it completely turned their business around. Even more interesting was the supplement that was added where they covered the same ideas of making user stories and really fleshing them out and then estimating them and telling people that you shouldn't just try these you need to commit to them and really do them. It does seem that at time a new system can be daunting but after reading this book and really trying to understand what theses kinds of different methods do and what these techniques promote in a group I really cannot see doing a system any differently. It seems that all the system does is simply drive forward the idea of writing good code and making sure you deliver it on time and essentially isn't that what any programming company wants to do? I really think this is a very good system and some of these supplements seem like they are going to answer my questions about what kinds of techniques are used in estimating and how pair programming can really help productivity.
Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley
Chapters 22-24:
In these chapters we effectively finish the book, only do find that there are extra bonus chapters that are simply supplements to the important foundations of the book. However before the book ends we do find out about one taboo in extreme programming and that is the idea of defects...or is it bugs....nope we are not allowed to say bugs! In fact the chapter stresses that we need to not call defects in our code bugs one because of the implication that it is a problem that is going to be persistent and two because it honestly scares the customers and we don't want to do that. There are many ways to handle these and of course the foremost among them is making tests for everything and making sure your tests work before adding your code to the program. Ironically enough this is where a lot of the major bu...I mean defects happen is in testing. However this is not to say that one should not test because testing is very important but you need to make sure to handle defects as they come and stay on top of them. The most important practice in extreme programming is having a plan and sticking to it and if you deviate from the plan there are multiple redundant checks to get you back on course. The conclusion of the book are actual testimonies of companies and groups who have used extreme programming and how much more they really enjoy it than their standard practices. Some groups have found a whole new way to run their business and deliver code thanks to extreme programming. They put a lot of emphasis and really reading the text and essentially making sure you follow the 8 basics of the system:
-On site Customers
-Small Releases
-Planning Based on Stories
-Programming Based on Metaphor
-Pair Programming
-Continuous Integration
-Testing
-Forty Hour Work Week
Keeping these and some other details in mind makes sure that the system effecitvely works and make sure that your team is going to get done what it needs to get done. Finally the last part of these chapters is a suppliment talking about stories and keeping to a track called "We'll try" it is the idea that every programmer has spoken these words and in some cases it can mean the end of the program before it even starts. In fact most people will give up on a program when they think that there is a task that they cannot estimate and this ultimately causes the program to fail. This is not the case and in fact some of these things really are as easy to implement as they make them sound like in the book. Sometimes it may be hard to get a start on them but ultimately they are fairly simple and they just need to be followed and practiced.
I think these chapters in the books were almost eye opening in that people think these kinds of things are rather difficult to do when really they are quite simple. I think the most interesting part of this was when they actually had testimonials of different groups talking about how they were able to implement these kinds of things and it completely turned their business around. Even more interesting was the supplement that was added where they covered the same ideas of making user stories and really fleshing them out and then estimating them and telling people that you shouldn't just try these you need to commit to them and really do them. It does seem that at time a new system can be daunting but after reading this book and really trying to understand what theses kinds of different methods do and what these techniques promote in a group I really cannot see doing a system any differently. It seems that all the system does is simply drive forward the idea of writing good code and making sure you deliver it on time and essentially isn't that what any programming company wants to do? I really think this is a very good system and some of these supplements seem like they are going to answer my questions about what kinds of techniques are used in estimating and how pair programming can really help productivity.
Tuesday, March 8, 2011
Book reading #15: The Inmates are Running the Asylum
The Inmates are Running the Asylum
Alan Cooper
Sams Publishing
Chapters 1&2:
In the first chapter we learn what the author thinks about computer scientists, and while not incorrect it is a bit of a revelation. That aside, he really does focus on a very important issue that computer scientists need to work on and that is the idea that when you have a computer embedded with something else, you still have A COMPUTER. Essentially, its the idea that despite the fact that you might have an AI or complex system that is able to make an informed decision when it boils down to it you still have a computer. He gives examples and shows that really when you peel back all the pain you really do just have a computer and not much more. He then does a rather nice job of transitioning this into the next chapter which is the idea of the big scare word in computer sceince, which is of course design. and how we are just now learning what design means and how to to it properly. In fact there are many, many teams that get together everyday to work on this concept and really dont turn out much than more advanced computers that can't do much more than anything that could before. He also talks about how because we are on the verge and really understand technology we are the best and the brightest and eventually it might be such that those who are considered extremely intelligent are those who are the most computer literate. He even goes so far as to talk about how computer literacy might be the new social norm and that we will form casts of who is and is not computer literate. It might be that technology is just a part of life but the way computers are going now and research is being done that is not an unreasonable claim.
I liked this book in these beginning chapters. His examples are good and I believe he puts in pictures where necessary, some really help, some help a little less so. The most interesting thing about this is that similar to Norman he kind of covers the same basic ideas of design and talks about a few of the same ideas, however he does them in a much more interesting way. I don't know if it is him giving better examples or not dwelling on one thing for too long but it was much more enjoyable. He does give a lot of different examples and really makes the reader want to understand by standing the examples and less so by just accepting what he says as the truth. I think the part where he tried to define computer scientists and I think for the most part this is due to the nature of computers. Sometimes they really don't seem to follow any logic and do be better job of giving headaches as opposed to being a useful input device. Dr. Stroustrup always tells us that "Computers are dumb beasts" and the unfortunate thing is that they are more dumb than beast for the most part. Once programming becomes more natural and we as a society become better at programming them this is likely to change but until that time we are still quite stuck.
Alan Cooper
Sams Publishing
Chapters 1&2:
In the first chapter we learn what the author thinks about computer scientists, and while not incorrect it is a bit of a revelation. That aside, he really does focus on a very important issue that computer scientists need to work on and that is the idea that when you have a computer embedded with something else, you still have A COMPUTER. Essentially, its the idea that despite the fact that you might have an AI or complex system that is able to make an informed decision when it boils down to it you still have a computer. He gives examples and shows that really when you peel back all the pain you really do just have a computer and not much more. He then does a rather nice job of transitioning this into the next chapter which is the idea of the big scare word in computer sceince, which is of course design. and how we are just now learning what design means and how to to it properly. In fact there are many, many teams that get together everyday to work on this concept and really dont turn out much than more advanced computers that can't do much more than anything that could before. He also talks about how because we are on the verge and really understand technology we are the best and the brightest and eventually it might be such that those who are considered extremely intelligent are those who are the most computer literate. He even goes so far as to talk about how computer literacy might be the new social norm and that we will form casts of who is and is not computer literate. It might be that technology is just a part of life but the way computers are going now and research is being done that is not an unreasonable claim.
Monday, March 7, 2011
Book Reading #14: The Mythical Man-Month
The Mythical Man-Month
Dr. Brooks
Addison Wesley Longman Inc.
Chapter1-3:
In these chapters we learn about a few fundamental concepts of computer science. First is the idea of the tar pit. The simple idea that many computer scientists who thought they were the best in the world have found themselves skining into the tar and becoming unable to find their way out. They are discouraged when a duo of people in their garage have accomplished something similar to theirs without realizing the degree to which it might work. The idea is put out to not get to overwhelmed by what others are doing and to focus on what you are doign and not everyone else. It is also mentioned to bear in mind the real tiger is always better than a paper one. The next is the premise of the book which is the mythical man month. The idea that man power and months of time can simply be traded based on the number of people doing the task and the amount of actual time is spent working on the gross of the material. As we know this is not true and the author talks about how adding more people can sometimes simply slow down due to having to teach everyone the system, get them caught up, and then divide tasks even further. It might also be that some of these people do not have enough programming experience and can end up only contributing little. Simply put, the idea that you can trade men for months is a poor notion and that it needs to be balanced correctly in orther to work well. Lastly the idea of the surgical team. This is the idea that each team of a group needs to be about 10 people and needs to be setup in a way such that each member has a job on the team and can perform their job well. It all starts with a head surgeon and then you have the co-pilot, the expters, the secretaries, the brains, and so on. Each person does a little part for the team and make sure everything goes out. He doesn't go into great detail about each of the jobs but simply an overview of each and how the team should interact as a whole. He ends by talking about how this can be the best unit for breaking a 100 year job into a 1 year job.
Each of these chapters had something unique about them. It wasn't that the information was new or that it was a clever idea or scheme that was not considered it is the way in which he presented the material that made it very easy to read. The simple idea of comparing the overhead of programming to a tar pit or the idea of having each group work like a surgical team with each person performing a job and everyone working to get a single task done. It is one of the things that is almost directly applicable to computer science where we can say, "yes we can have this person do this and this person this etc..." each one doing a single job and worrying only about their end. That is not to say that if someone is slacking jobs cannot blend but for the most part but each person primarily should stick to theirs. The idea of the man-month was a bit more confusing but i think the premise is correct that having more people does not necessarily get you to finish something faster. You ahve to consider other ideas such as how to train the people and how to get them up to speed on the current system, it is not a cut and dry matter of throw more people at it until it works. All of them are great ideas and as I said were presented in such an easy to understand way that it made the reading enjoyable. When I am less tired I will probably enjoy this quite a bit more.
Dr. Brooks
Addison Wesley Longman Inc.
Chapter1-3:
In these chapters we learn about a few fundamental concepts of computer science. First is the idea of the tar pit. The simple idea that many computer scientists who thought they were the best in the world have found themselves skining into the tar and becoming unable to find their way out. They are discouraged when a duo of people in their garage have accomplished something similar to theirs without realizing the degree to which it might work. The idea is put out to not get to overwhelmed by what others are doing and to focus on what you are doign and not everyone else. It is also mentioned to bear in mind the real tiger is always better than a paper one. The next is the premise of the book which is the mythical man month. The idea that man power and months of time can simply be traded based on the number of people doing the task and the amount of actual time is spent working on the gross of the material. As we know this is not true and the author talks about how adding more people can sometimes simply slow down due to having to teach everyone the system, get them caught up, and then divide tasks even further. It might also be that some of these people do not have enough programming experience and can end up only contributing little. Simply put, the idea that you can trade men for months is a poor notion and that it needs to be balanced correctly in orther to work well. Lastly the idea of the surgical team. This is the idea that each team of a group needs to be about 10 people and needs to be setup in a way such that each member has a job on the team and can perform their job well. It all starts with a head surgeon and then you have the co-pilot, the expters, the secretaries, the brains, and so on. Each person does a little part for the team and make sure everything goes out. He doesn't go into great detail about each of the jobs but simply an overview of each and how the team should interact as a whole. He ends by talking about how this can be the best unit for breaking a 100 year job into a 1 year job.
Each of these chapters had something unique about them. It wasn't that the information was new or that it was a clever idea or scheme that was not considered it is the way in which he presented the material that made it very easy to read. The simple idea of comparing the overhead of programming to a tar pit or the idea of having each group work like a surgical team with each person performing a job and everyone working to get a single task done. It is one of the things that is almost directly applicable to computer science where we can say, "yes we can have this person do this and this person this etc..." each one doing a single job and worrying only about their end. That is not to say that if someone is slacking jobs cannot blend but for the most part but each person primarily should stick to theirs. The idea of the man-month was a bit more confusing but i think the premise is correct that having more people does not necessarily get you to finish something faster. You ahve to consider other ideas such as how to train the people and how to get them up to speed on the current system, it is not a cut and dry matter of throw more people at it until it works. All of them are great ideas and as I said were presented in such an easy to understand way that it made the reading enjoyable. When I am less tired I will probably enjoy this quite a bit more.
Book Reading #13: Extreme Programming Installed
Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley
Chapters 19-21:
In these chapters we find out all about steering a project and how it can drastically affect the outcome as well has having someone who helps with gathering results of a project and making sure everyone is on track. As you go through a project you want to be sure to have a tracker and make sure that the tracker is keeping tabs on everyone and where they are on their comitments. The person wants to be personable and easy to talk to and not be threatening or make people feel like they're not doing well. You want to do this regualarly to make sure that everyone is staying on track and steering the project when necessary. You also want to be sure to steer the iteration and the release in the same way. You want to be sure to get your most important stories done first and make sure that you have as many components of your release ready as possible. You might want to also be sure to contact the customer and inform him of any delays that you might have. The authors emphasize that understanding that each set back is the entire teams problem and not one persons problem is a big help here and making sure that each person is working towards the goal at all times is key. You as the manager want to make sure that everyone is on task and that you can help as many people at once as possible and steer the project.
I think that these chapters are only useful at all if you are the manager. IF you are an average working on the project it is a good idea to understand what is going on but you might not be interacting with people a whole lot. The biggest thing they cover here is the idea of steering and making sure that you get the things out that need to be out. The tracker is a good idea but in some groups this will be difficult for someone to do. You need to make sure you have the right kind of person and that the person is not intimidating anyone. You also need to be sure that if something isn't going as planned that you do make sure you keep the project on track and see what you can do to keep it going. If someone has gotten behind you might even have to do some programming yourself but this is all for the good of the team. I would definitely want to keep these things in mind if I ever manage a programming team and remember that it is an entire team practice and that no one is taking on more or less than anyone else.
Subscribe to:
Comments (Atom)