The Mythical Man-Month
Frederick Brooks
Summary:
Chapter 13:
This chapter focuses on three main things, how to design you program to avoid bugs, component debugging, and system debugging. One way to design your program to avoid errors is to use a top down approach which basically modularize s the project. Component debugging is basically what programmers use now to debug programs and at it's current state, it is interactive. Programmers can go back and forth between testing their code and writing it.
Chapter 14:
This chapter focuses on not letting delays in the schedule become compounded. Basically, do your best to not fall behind and if you do, do not let that delay push back anything else or else it could turn into a catastrophe. A PERT chart is useful for this because it doesn't allow the delays to go unnoticed and gives everyone a clear picture of where the project stands.
Chapter 15:
This chapter focuses on what documentation is required for any project. The main documentation needed is how to use this program. This also includes the purpose of the program as well as basic requirements needed to run the program and many others. Self documenting code is where we are headed and for the most part it works very well.
Discussion:
These chapters focus on 3 things that most programmers are less than excited about doing. Even though these tasks seem extremely tedious, they often a key part of successful and well written programs. Personally, debugging isn't too bad for the most part as long as the code is written well. Poorly written and commented code makes debugging a nightmare. It is best to have some standard for you code so that it is easy for everyone to debug it later. Also, documentation is probably a programmers worst nightmare but now that we have self documenting code, it is starting to become much easier.
Tuesday, April 12, 2011
Tuesday, March 22, 2011
The Mythical Man-Month: Chapters 1-3
Mythical Man Month
by Frederick P. Brooks
Somehow I didn't realize we had three readings last week so I am doing this one first before i do the next three chapters. Software engineering has really become a tar pit. It doesn't matter how big a company you are, you are still susceptible. Any program can be made better with more time and money, but that isn't necessarily efficient. Most programmers enjoy what they do because of the creative freedom they are given. This doesn't mean however that there are times when programmers get really frustrated. Usually it is when one tiny thing is wrong and you can't figure it out to save your life. Most programmers are optimists and not for the reason you would think. Are creative material is all in are head not much unlike an artist. Things that seem easy in our head are not actually as easy as we thought when we actually start to create it "physically". This is usually one of the reasons programmers are notorious for extremely inaccurate estimates. Mangers favor a small surgical team of extremely capable programmers to create all of their software. However, this is really impossible to do for a large scale program. You really do need a large amount of programmers in order for you to finish it sometime this century. People have proposed new designs in order to tackle this problem but nothing extremely solid has taken off yet.
I always find it interesting on how people try to distill software development into something less complicated. Usually they don't succeed or it doesn't actually make sense in reality. Why do we need to try and make it less complicated than it is? I think that effective software engineering must be solved on a case by case basis. There are so many different factors from one project to another that it is almost impossible to have a similar development process. So instead of trying to make a development process we can follow, why don't we focus on things that good software developers do in common. I think this would be more beneficial in the long run than trying to dumb down software development.
by Frederick P. Brooks
Somehow I didn't realize we had three readings last week so I am doing this one first before i do the next three chapters. Software engineering has really become a tar pit. It doesn't matter how big a company you are, you are still susceptible. Any program can be made better with more time and money, but that isn't necessarily efficient. Most programmers enjoy what they do because of the creative freedom they are given. This doesn't mean however that there are times when programmers get really frustrated. Usually it is when one tiny thing is wrong and you can't figure it out to save your life. Most programmers are optimists and not for the reason you would think. Are creative material is all in are head not much unlike an artist. Things that seem easy in our head are not actually as easy as we thought when we actually start to create it "physically". This is usually one of the reasons programmers are notorious for extremely inaccurate estimates. Mangers favor a small surgical team of extremely capable programmers to create all of their software. However, this is really impossible to do for a large scale program. You really do need a large amount of programmers in order for you to finish it sometime this century. People have proposed new designs in order to tackle this problem but nothing extremely solid has taken off yet.
I always find it interesting on how people try to distill software development into something less complicated. Usually they don't succeed or it doesn't actually make sense in reality. Why do we need to try and make it less complicated than it is? I think that effective software engineering must be solved on a case by case basis. There are so many different factors from one project to another that it is almost impossible to have a similar development process. So instead of trying to make a development process we can follow, why don't we focus on things that good software developers do in common. I think this would be more beneficial in the long run than trying to dumb down software development.
The Inmates are Running the Asylum Chapter 3-5
The Inmates are Running the Asylum
by Alan Cooper
Chapters 3,4, and 5 are titled wasting money, the dancing bear, and customer disloyalty, respectively. People thing it is really easy to waste millions of dollars but the truth of it is that it really isn't. One key issue that results in wasting money is deadline management. People will push and push to meet a deadline spending extra money just to reach it and when they finally get there, they realize that they still have more to do. Managers worry about two major things which are if the programmers will be able to finish and whether the product will succeed. This makes a manager feel like the programming needs to get started as soon as possible and finish as soon as possible. This can really hurt a project especially if your coders are programming without direction. You could be wasting valuable time and resources because the programmers don't have the overall picture. Bad software is everywhere these days. Most people don't even realize that it is bad because it is all they have used and until they see a good product, they will be ignorant. How to programmers create good programs? It is not so much the programmers fault as one would think. Software in itself has a lot of constraints that prevent it from being friendly. It is inflexible, it can't remember, etc. This really makes it difficult to create a program that is easy and friendly to use. We are inclined to create good products because of the customer loyalty it generates. In software engineering, it seems like the level of loyalty is tenfold. This customer loyalty is a huge benefit to a company because it almost acts like a networking device. Without that loyalty, your company is suspect to competition.
These three issues that the author addresses are extremely important in present times. I have had my fair share of crappy software and it really drives me nuts especially being a computer scientist. The sad part is is that there isn't much a person can do individually to affect the creation of bad software. You honestly have to just hope that there is something better out there to use. In the case of our elearning site, there isn't... This doesn't make me lose all hope however because there truly is some amazing programs out there. We need a better way to hold companies accountable for the software they produce. I know that usually are free market will take care of it and weed out the companies that aren't deserving but what if it really is the only product that you can use. Would you rather be stuck with a bad program or not having any program?
by Alan Cooper
Chapters 3,4, and 5 are titled wasting money, the dancing bear, and customer disloyalty, respectively. People thing it is really easy to waste millions of dollars but the truth of it is that it really isn't. One key issue that results in wasting money is deadline management. People will push and push to meet a deadline spending extra money just to reach it and when they finally get there, they realize that they still have more to do. Managers worry about two major things which are if the programmers will be able to finish and whether the product will succeed. This makes a manager feel like the programming needs to get started as soon as possible and finish as soon as possible. This can really hurt a project especially if your coders are programming without direction. You could be wasting valuable time and resources because the programmers don't have the overall picture. Bad software is everywhere these days. Most people don't even realize that it is bad because it is all they have used and until they see a good product, they will be ignorant. How to programmers create good programs? It is not so much the programmers fault as one would think. Software in itself has a lot of constraints that prevent it from being friendly. It is inflexible, it can't remember, etc. This really makes it difficult to create a program that is easy and friendly to use. We are inclined to create good products because of the customer loyalty it generates. In software engineering, it seems like the level of loyalty is tenfold. This customer loyalty is a huge benefit to a company because it almost acts like a networking device. Without that loyalty, your company is suspect to competition.
These three issues that the author addresses are extremely important in present times. I have had my fair share of crappy software and it really drives me nuts especially being a computer scientist. The sad part is is that there isn't much a person can do individually to affect the creation of bad software. You honestly have to just hope that there is something better out there to use. In the case of our elearning site, there isn't... This doesn't make me lose all hope however because there truly is some amazing programs out there. We need a better way to hold companies accountable for the software they produce. I know that usually are free market will take care of it and weed out the companies that aren't deserving but what if it really is the only product that you can use. Would you rather be stuck with a bad program or not having any program?
Extreme Programming installed: Chapters 22-24
Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These three chapters cover handling defects, a wrap up of extreme programming, and the we will try mentality. First and for most, never call defects bugs. Bugs are random errors that pop up at of nowhere. The reason we should call them defects is because some programmer has intentionally put in the bug making it not random. Usually, it wasn't intended to have that particular effect which results in a defect in the code. As soon as a defect is detected it should be reported immediately so that a correction can be put into place. Defects reduce the quality of our program and thus its worth to the company we are making it for. The wrap up is basically a conclusion of the previous chapters. They stress again some of the essential features XP brings to the table. On site customers, small releases, and collective code ownership are just a few of the important aspects of extreme programming. The we will try mentality is when the team is presented with a problem to solve or a program to build but are not looking forward to doing it because they know that it will be extremely grueling and time consuming. XP helps to get rid of this mentality because you know exactly what you have to do down to the smallest interaction. Programmers can adequately get the scope of the project without feeling overwhelmed which eliminates the we'll try. Now it is we can do.
Defects are always going to be an issue whether you plan for them are not. The key is how you go about fixing them. It would almost be useful once code is being submitted and finalized to have a team of a couple programmers just try to find and fix bugs. If they can't fix it, they can report it back to the person who wrote the code in order for them to either give some clarification or fix it themselves. This would allow your design team to keep pushing out content instead of having to go back and constantly debug code. Errors might pile up depending on the quality of your programmers but this shouldn't be an issue because your design team will get done faster. Then they can help out with proofing code and bringing it up to standard.
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These three chapters cover handling defects, a wrap up of extreme programming, and the we will try mentality. First and for most, never call defects bugs. Bugs are random errors that pop up at of nowhere. The reason we should call them defects is because some programmer has intentionally put in the bug making it not random. Usually, it wasn't intended to have that particular effect which results in a defect in the code. As soon as a defect is detected it should be reported immediately so that a correction can be put into place. Defects reduce the quality of our program and thus its worth to the company we are making it for. The wrap up is basically a conclusion of the previous chapters. They stress again some of the essential features XP brings to the table. On site customers, small releases, and collective code ownership are just a few of the important aspects of extreme programming. The we will try mentality is when the team is presented with a problem to solve or a program to build but are not looking forward to doing it because they know that it will be extremely grueling and time consuming. XP helps to get rid of this mentality because you know exactly what you have to do down to the smallest interaction. Programmers can adequately get the scope of the project without feeling overwhelmed which eliminates the we'll try. Now it is we can do.
Defects are always going to be an issue whether you plan for them are not. The key is how you go about fixing them. It would almost be useful once code is being submitted and finalized to have a team of a couple programmers just try to find and fix bugs. If they can't fix it, they can report it back to the person who wrote the code in order for them to either give some clarification or fix it themselves. This would allow your design team to keep pushing out content instead of having to go back and constantly debug code. Errors might pile up depending on the quality of your programmers but this shouldn't be an issue because your design team will get done faster. Then they can help out with proofing code and bringing it up to standard.
Tuesday, March 8, 2011
The Inmates are Running the Asylum Chapter 1-2
The Inmates are Running the Asylum
by Alan Cooper
In these chapters Mr. Cooper talks about how pretty much anything with a computer in is still subject to the laws that define computers. Computers are extremely logical. They are really good at giving you factual information but that does not always make it correct. Human error coupled with computers can be disastrous as given in the example of the airplane crash. The airplane allowed the pilot to turn right into a 10000 ft. cliff face because that was the direction to the target. Although it was blamed on the pilot, it shouldn't be hard to program terrain into the navigation system of an airplane to warn about these kind of things. Computers are not cognitive. They cannot reason. All they can do is make factual calculations.
Humans are extremely susceptible to routines. Computers help us to make our lives easier but at the same time, we tend to become lackadaisical. We really so much on the computer that we become dependent on them. In the future, cars and planes will probably be flown by computers. We might or might not have back up pilots/drivers just in case the computer screws up. Imagine having a back up pilot fly a plane when he has been dependent on the computer to fly it for however many years. I know i would not be comfortable in that situation. I really do think computers are great i still think there needs to be some kind of manual backup just in case.
by Alan Cooper
In these chapters Mr. Cooper talks about how pretty much anything with a computer in is still subject to the laws that define computers. Computers are extremely logical. They are really good at giving you factual information but that does not always make it correct. Human error coupled with computers can be disastrous as given in the example of the airplane crash. The airplane allowed the pilot to turn right into a 10000 ft. cliff face because that was the direction to the target. Although it was blamed on the pilot, it shouldn't be hard to program terrain into the navigation system of an airplane to warn about these kind of things. Computers are not cognitive. They cannot reason. All they can do is make factual calculations.
Humans are extremely susceptible to routines. Computers help us to make our lives easier but at the same time, we tend to become lackadaisical. We really so much on the computer that we become dependent on them. In the future, cars and planes will probably be flown by computers. We might or might not have back up pilots/drivers just in case the computer screws up. Imagine having a back up pilot fly a plane when he has been dependent on the computer to fly it for however many years. I know i would not be comfortable in that situation. I really do think computers are great i still think there needs to be some kind of manual backup just in case.
Extreme Programming installed: Chapters 19-21
Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These three chapters cover steering, steering the iteration, and steering the release. Steering is basically the idea of estimating actively. If you can tell that a particular story is going slow, look for similar stories and estimate them again based on what you learned from the story that was slowing you up. For steering in an iteration, you need to focus on getting tasks done. having 9 out of 10 tasks completely done is better than having 90% of ten tasks done. You don't want to get to your deadline without having anything completed. Steering allows you to move and adjust stories on the fly during an iteration so that things don't fall behind. It also might be useful to have a tracker. This person stays up to date with each story that a person has picked up and makes sure that it is staying on time or running behind. If it is late, he needs to find out why. The two main things to you will not at the release level is when you are going to be done and what you are going to have done when you get there. You should have a fairly good estimate by the time of release just exactly what your team can accomplish by then. This is due to the fact that your programmers should know how much they can accomplish each sprint.
Steering for the most part seems like something every good manager should do. They need to keep track of the pace of their employees and make it easier for them to get their work done. This is by no means just an extreme programming idea. If companies can't keep track of the pace of their projects, they are not going to be able to accurately estimate their completion. If they can't do that, then they are really susceptible to pushing back deadlines. By steering your project, you can almost guide it to a specific release date just because you are in tune with the flow of your project.
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These three chapters cover steering, steering the iteration, and steering the release. Steering is basically the idea of estimating actively. If you can tell that a particular story is going slow, look for similar stories and estimate them again based on what you learned from the story that was slowing you up. For steering in an iteration, you need to focus on getting tasks done. having 9 out of 10 tasks completely done is better than having 90% of ten tasks done. You don't want to get to your deadline without having anything completed. Steering allows you to move and adjust stories on the fly during an iteration so that things don't fall behind. It also might be useful to have a tracker. This person stays up to date with each story that a person has picked up and makes sure that it is staying on time or running behind. If it is late, he needs to find out why. The two main things to you will not at the release level is when you are going to be done and what you are going to have done when you get there. You should have a fairly good estimate by the time of release just exactly what your team can accomplish by then. This is due to the fact that your programmers should know how much they can accomplish each sprint.
Steering for the most part seems like something every good manager should do. They need to keep track of the pace of their employees and make it easier for them to get their work done. This is by no means just an extreme programming idea. If companies can't keep track of the pace of their projects, they are not going to be able to accurately estimate their completion. If they can't do that, then they are really susceptible to pushing back deadlines. By steering your project, you can almost guide it to a specific release date just because you are in tune with the flow of your project.
Tuesday, March 1, 2011
The Design of Future things: Chapter 6
The Design of Future things
Donald A. Norman
This chapter covers awareness. When riding a horse, the rider is constantly aware of the horse. He can interpret the horses mood, energy level, etc. by just being there. This is inherently different than machines. In most cases when machines try to make us aware, it is just annoying. At the same time, it is usually necessary. Imagine trying to connect your computer to the internet without any kind of feedback. The only way you will know your computer is connected when you are able to access the internet. If you are able to access the internet, its fine. If you are not, however, it is really annoying. The trick is to create awareness for machines while not making them annoying.
Computers are some of the most susceptible to being annoying and aware at the same time. It is not so much the computers fault as it is the ability of the user. For extremely vanilla users, having all the checks and tutorials is a good thing. However, for a senior computer science major, they tend to just be in the way. It would be nice for a computer to be told the capabilities of the user. Then the computer could change its user settings based on the capabilities of the user. This is almost a way to bypass awareness in the way that it varies its control based on the users ability and understanding of the computer itself.
Donald A. Norman
This chapter covers awareness. When riding a horse, the rider is constantly aware of the horse. He can interpret the horses mood, energy level, etc. by just being there. This is inherently different than machines. In most cases when machines try to make us aware, it is just annoying. At the same time, it is usually necessary. Imagine trying to connect your computer to the internet without any kind of feedback. The only way you will know your computer is connected when you are able to access the internet. If you are able to access the internet, its fine. If you are not, however, it is really annoying. The trick is to create awareness for machines while not making them annoying.
Computers are some of the most susceptible to being annoying and aware at the same time. It is not so much the computers fault as it is the ability of the user. For extremely vanilla users, having all the checks and tutorials is a good thing. However, for a senior computer science major, they tend to just be in the way. It would be nice for a computer to be told the capabilities of the user. Then the computer could change its user settings based on the capabilities of the user. This is almost a way to bypass awareness in the way that it varies its control based on the users ability and understanding of the computer itself.
Subscribe to:
Comments (Atom)