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.
Extreme Programming installed: Chapters 16-18
Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson
Now that most of the programming aspects have been covered, these next 3 chapters look at various other issues in regards to extreme programming. Chapter 16 covers the do's and don'ts of XP. Some of their key recommendations include designing all the time. You should continuously try to make your designs a reality. Focus on communication as it is a key aspect of a successful XP environment. Some of the don'ts include not freezing your requirements before you start coding, designing the whole system before implementing, and don't separate the teams into designers and coders. In the next chapter, they discuss how experience improves estimation. The four rules of estimating are estimate each task you sign up for, estimate the amount of time you will spend working, pay attention to the actual amount of time it took you, and then reflect upon it. This process will allow you to understand your pace and velocity for various tasks. Chapter 18 covers some aspects that deal with your interaction with the customer. It is very important to keep track of scope, resources, quality, and time. Keeping up with these things will give you more leverage if for some reason you fail to meet a deadline, etc.
Ron Jeffries, Ann Anderson, and Chet Hendrickson
Now that most of the programming aspects have been covered, these next 3 chapters look at various other issues in regards to extreme programming. Chapter 16 covers the do's and don'ts of XP. Some of their key recommendations include designing all the time. You should continuously try to make your designs a reality. Focus on communication as it is a key aspect of a successful XP environment. Some of the don'ts include not freezing your requirements before you start coding, designing the whole system before implementing, and don't separate the teams into designers and coders. In the next chapter, they discuss how experience improves estimation. The four rules of estimating are estimate each task you sign up for, estimate the amount of time you will spend working, pay attention to the actual amount of time it took you, and then reflect upon it. This process will allow you to understand your pace and velocity for various tasks. Chapter 18 covers some aspects that deal with your interaction with the customer. It is very important to keep track of scope, resources, quality, and time. Keeping up with these things will give you more leverage if for some reason you fail to meet a deadline, etc.
The first to chapters I felt were almost like a review for what we should of learned from the previous 15 chapters. If you want to understand the essence of XP, you can probably just read chapters 16 and 17. Here they distill XP down into the key aspects you should use when you are programming and estimating. I use agile development where I work. For the most part, it is fairly easy to understand, but I have to be careful when talking to the client and accidentally set a release date that is not realistic. It is much better to give yourself a slight cushion and deliver it early than deliver it late.
Tuesday, February 22, 2011
The Design of Future things: Chapter 5
The Design of Future things
Donald A. Norman
In this chapter, Mr. Norman discusses automation and how the current trend for technology is heading that way. Automation in itself is not all it is cut out to be. We use automation to do tasks for us that we might consider menial or time consuming but at the same time, it spawns a whole other set of things for us to do. Mr. Norman gives an example of how a coffee machine makes coffee automatically for us. Even though it didn't take much effort to begin with, in the morning, we really don't want to do it. So having the automation in this case helps us. This automation creates some minor inconveniences. After we have had the coffee made for us, we now have to empty the grounds, remove the filter, and clean the whole unit. A group at Microsoft is also looking into automation but as more of a helper for humans and not a replacement. This is currently being researched for use in smart homes. These homes would help busy families with scheduling and planning during the week.
Automation has its benefits but I think it should be used to supplement human effort rather than replace it. Technology may not always be there and we cannot afford to forget how to do things without technology. That is why automation should supplement human effort that way we always still have some responsibility or task we can do. I think the smart home idea is really cool especially for a busy family. If it could be used to help find more time that families can spend together, it is definitely worth it.
Donald A. Norman
In this chapter, Mr. Norman discusses automation and how the current trend for technology is heading that way. Automation in itself is not all it is cut out to be. We use automation to do tasks for us that we might consider menial or time consuming but at the same time, it spawns a whole other set of things for us to do. Mr. Norman gives an example of how a coffee machine makes coffee automatically for us. Even though it didn't take much effort to begin with, in the morning, we really don't want to do it. So having the automation in this case helps us. This automation creates some minor inconveniences. After we have had the coffee made for us, we now have to empty the grounds, remove the filter, and clean the whole unit. A group at Microsoft is also looking into automation but as more of a helper for humans and not a replacement. This is currently being researched for use in smart homes. These homes would help busy families with scheduling and planning during the week.
Automation has its benefits but I think it should be used to supplement human effort rather than replace it. Technology may not always be there and we cannot afford to forget how to do things without technology. That is why automation should supplement human effort that way we always still have some responsibility or task we can do. I think the smart home idea is really cool especially for a busy family. If it could be used to help find more time that families can spend together, it is definitely worth it.
Extreme Programming installed: Chapters 13-15
Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These next three chapters cover unit tests, test driven programming, and how to handle release changes. For unit tests, the programmer needs to be able to test every single class and method and that test needs to run 100 percent of the time. We do this by writing code that tests each method or class within our current project code. This can be quite overwhelming especially if you have a large project. That is where the next chapter comes in. Basically, in extreme programming, you want the tests to drive the coding. Why write new code when your tests already tell you that the current code can handle everything you need it to. You should only write new code when one of your tests fails. Also, XP is notorious for lack of planning. They don't focus on how to do something, rather, on what they need to do. This is called programming by intention. Collective code ownership is very important to XP. It allows things to get done faster and at a higher quality since programmers don't have to wait for permission. At the same time, releasing changes becomes a lot more important. There are three main steps that pair typically follows which are called local, release candidate, and released to the repository.
I have never really used any of these ideas too much at work but I know they are used on some of the larger projects. I know that unit tests are important but sometimes i feel like they take more time than the actual coding process. I think there needs to be a balance between how much testing as done and the actual coding. If you focus on too much on one aspect or the other, you tend to treat the other with less focus. That is why there needs to be a balance and the project lead should be responsible for that.
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These next three chapters cover unit tests, test driven programming, and how to handle release changes. For unit tests, the programmer needs to be able to test every single class and method and that test needs to run 100 percent of the time. We do this by writing code that tests each method or class within our current project code. This can be quite overwhelming especially if you have a large project. That is where the next chapter comes in. Basically, in extreme programming, you want the tests to drive the coding. Why write new code when your tests already tell you that the current code can handle everything you need it to. You should only write new code when one of your tests fails. Also, XP is notorious for lack of planning. They don't focus on how to do something, rather, on what they need to do. This is called programming by intention. Collective code ownership is very important to XP. It allows things to get done faster and at a higher quality since programmers don't have to wait for permission. At the same time, releasing changes becomes a lot more important. There are three main steps that pair typically follows which are called local, release candidate, and released to the repository.
I have never really used any of these ideas too much at work but I know they are used on some of the larger projects. I know that unit tests are important but sometimes i feel like they take more time than the actual coding process. I think there needs to be a balance between how much testing as done and the actual coding. If you focus on too much on one aspect or the other, you tend to treat the other with less focus. That is why there needs to be a balance and the project lead should be responsible for that.
Tuesday, February 15, 2011
The Design of Future things: Chapter 4
The Design of Future things
Donald A. Norman
As machines become more and more complex, they run the risk of having severe side effects. It all comes down to degrees of control. It is always the unexpected consequences of technology that have the biggest consequences. The bad usually make headlines. Nearly every major technological tragedy was do to unforeseeable consequences. Some people complain that we are becoming slaves to machines and in many ways we are but people do not see it as slavery. Machines make it easier for us to live and people usually aren't willing to give that up. More and more, machines are heading towards full automation. Imagine having cars that drive themselves or appliances that just know what to do based on what you put in or on them. Overautomation can be a problem however. In some situations, your really do need to have a human presence in a machine just to account for unexpected variables. If machines are overautomated, people tend to get to relaxed because they assume that nothing is going to happen. There really is a fine line between automation and overautomation.
I for one would like more automation in machines especially when on the road. It would be much safer if we could take the human's out of control of vehicles. I would wager that 99% of all accidents are human related. If we take out that, car wrecks would be virtually non existent. The only issue with humans being so dependent on machines is that we may not be prepared for life without them. Emp's will pretty much render all machines useless now since almost every machine has a computer in it. So if for some reason we weren't sent back to the stone age because all of our machines were disabled, humans might not have the skills necessary to survive.
Donald A. Norman
As machines become more and more complex, they run the risk of having severe side effects. It all comes down to degrees of control. It is always the unexpected consequences of technology that have the biggest consequences. The bad usually make headlines. Nearly every major technological tragedy was do to unforeseeable consequences. Some people complain that we are becoming slaves to machines and in many ways we are but people do not see it as slavery. Machines make it easier for us to live and people usually aren't willing to give that up. More and more, machines are heading towards full automation. Imagine having cars that drive themselves or appliances that just know what to do based on what you put in or on them. Overautomation can be a problem however. In some situations, your really do need to have a human presence in a machine just to account for unexpected variables. If machines are overautomated, people tend to get to relaxed because they assume that nothing is going to happen. There really is a fine line between automation and overautomation.
I for one would like more automation in machines especially when on the road. It would be much safer if we could take the human's out of control of vehicles. I would wager that 99% of all accidents are human related. If we take out that, car wrecks would be virtually non existent. The only issue with humans being so dependent on machines is that we may not be prepared for life without them. Emp's will pretty much render all machines useless now since almost every machine has a computer in it. So if for some reason we weren't sent back to the stone age because all of our machines were disabled, humans might not have the skills necessary to survive.
Extreme Programming installed: Chapters 10-12
Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These next three chapter are fairly important for extreme programming to be successful. They cover quick design sessions, programming/code quality, and pair programming. Typically in XP, once the user stories are done, most people jump into test first programming. If you are consistently running into situations where you have to have design sessions, it is possible that your user stories are to large. On the rare occasion though, it can be useful to take about 10 to 15 minutes to sketch out a basic design structure. This design meetings should never go over 30 minutes in length. Programming in XP projects are done in pairs for production coding. Your partner will probably change quite frequently based on what your are working on. Each pair is given and task and is required to complete that coding assignment. They can test its completeness through a unit test which tests every possible thing that can go wrong. If the unit test returns 100, then the item is ready for production and deployment. Within XP, there is the idea of Collective Code ownership. This basically means that all of the programmers are responsible for all the code. If a programmer needs to modify an existing class to add some utility, he can do that without consulting the person who wrote the class initially. This allows a programmer to create much quicker solutions and gets rid of the middle man when it comes to fixing problems or adding functionality. Pair programming is another essential part to XP. Having two people writing the code actually produces better code faster and you also have 2 people who understand it instead of 2 people who only understand half of it. The pair should both be actively helping program even if you are not the driver.
XP does some things that most programmers would think would not actually help production. The lack of design meetings is one of them. Honestly, sometimes having an overall structure can be useful and should be done but most of the time, it usually isn't necessary. The structure will usually define itself as the project goes along. Programming and code quality are important for any programming type, not just XP. It is important that the programming lead determine a coding style for the whole project. Without it, you run the risk of writing code that your colleagues might have trouble interpreting. I've never actually done pair programming but I think it would be really helpful. Sometime I feel like I waste so much time looking things up that someone else probably already knows how to do. It is also useful to help train some of your newer employees. By having them help out a senior programmer, they gain valuable experience while also contributing to the project.
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These next three chapter are fairly important for extreme programming to be successful. They cover quick design sessions, programming/code quality, and pair programming. Typically in XP, once the user stories are done, most people jump into test first programming. If you are consistently running into situations where you have to have design sessions, it is possible that your user stories are to large. On the rare occasion though, it can be useful to take about 10 to 15 minutes to sketch out a basic design structure. This design meetings should never go over 30 minutes in length. Programming in XP projects are done in pairs for production coding. Your partner will probably change quite frequently based on what your are working on. Each pair is given and task and is required to complete that coding assignment. They can test its completeness through a unit test which tests every possible thing that can go wrong. If the unit test returns 100, then the item is ready for production and deployment. Within XP, there is the idea of Collective Code ownership. This basically means that all of the programmers are responsible for all the code. If a programmer needs to modify an existing class to add some utility, he can do that without consulting the person who wrote the class initially. This allows a programmer to create much quicker solutions and gets rid of the middle man when it comes to fixing problems or adding functionality. Pair programming is another essential part to XP. Having two people writing the code actually produces better code faster and you also have 2 people who understand it instead of 2 people who only understand half of it. The pair should both be actively helping program even if you are not the driver.
XP does some things that most programmers would think would not actually help production. The lack of design meetings is one of them. Honestly, sometimes having an overall structure can be useful and should be done but most of the time, it usually isn't necessary. The structure will usually define itself as the project goes along. Programming and code quality are important for any programming type, not just XP. It is important that the programming lead determine a coding style for the whole project. Without it, you run the risk of writing code that your colleagues might have trouble interpreting. I've never actually done pair programming but I think it would be really helpful. Sometime I feel like I waste so much time looking things up that someone else probably already knows how to do. It is also useful to help train some of your newer employees. By having them help out a senior programmer, they gain valuable experience while also contributing to the project.
Tuesday, February 8, 2011
Extreme Programming installed: Chapters 7-9
Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These three chapters cover small releases, customer defined release, and and iteration planning. XP projects rely on quick releases. The only way to do this is to make iterative small releases. By doing this, the customer always has some kind of product with some kind of basic functionality. By doing quick small releases, your customer is constantly giving you feedback on the direction on the project. This allows you and the customer a greater level of understanding. The project will be on track and please the customer much faster. In XP, the customer decides the release date based on how they assign the releases. Sometimes the customer has a hard time creating user stories that are able to be done in small releases. If this is the case, the customer needs to be there when the programmers are grading the user story on difficulty. Stories cannot be rated in months so the customer really has to learn how to define user stories on a smaller scale. This should get better as the project moves along. Since the customer is making the user stories, he is also determining the release date of certain tasks. This helps to define the priorities of the project. This goes hand and hand with iteration planning. The customer is responsible for determining what gets done each iteration. So a programming team has a velocitry of 30 points. In the planning meeting, the customer presents the user stories, the team brainstorms the tasks, and then each programmer picks a task. Each of these tasks have a point value associated with them which in turn determines how much work the team will be doing this iteration.
These 3 chapter focus more on the practicing side of XP. It defines what exactly goes on in the planning process fro each iteration. Some people really like this part of XP while others really hate it. It largely depends on the people in your programming team. It takes a lot of self discipline in order to pick a task and then complete it before the end of the given period. Sometimes teams run into issues when certain people are not pulling there weight. I have actually run into this a couple times when certain people have not pulled their weight. This usually forces someone to step up to the plate and take on extra work in order to keep the iterations on time. It really isn't fair for that person and increases the overall stress associated with the project.
Ron Jeffries, Ann Anderson, and Chet Hendrickson
These three chapters cover small releases, customer defined release, and and iteration planning. XP projects rely on quick releases. The only way to do this is to make iterative small releases. By doing this, the customer always has some kind of product with some kind of basic functionality. By doing quick small releases, your customer is constantly giving you feedback on the direction on the project. This allows you and the customer a greater level of understanding. The project will be on track and please the customer much faster. In XP, the customer decides the release date based on how they assign the releases. Sometimes the customer has a hard time creating user stories that are able to be done in small releases. If this is the case, the customer needs to be there when the programmers are grading the user story on difficulty. Stories cannot be rated in months so the customer really has to learn how to define user stories on a smaller scale. This should get better as the project moves along. Since the customer is making the user stories, he is also determining the release date of certain tasks. This helps to define the priorities of the project. This goes hand and hand with iteration planning. The customer is responsible for determining what gets done each iteration. So a programming team has a velocitry of 30 points. In the planning meeting, the customer presents the user stories, the team brainstorms the tasks, and then each programmer picks a task. Each of these tasks have a point value associated with them which in turn determines how much work the team will be doing this iteration.
These 3 chapter focus more on the practicing side of XP. It defines what exactly goes on in the planning process fro each iteration. Some people really like this part of XP while others really hate it. It largely depends on the people in your programming team. It takes a lot of self discipline in order to pick a task and then complete it before the end of the given period. Sometimes teams run into issues when certain people are not pulling there weight. I have actually run into this a couple times when certain people have not pulled their weight. This usually forces someone to step up to the plate and take on extra work in order to keep the iterations on time. It really isn't fair for that person and increases the overall stress associated with the project.
The Design of Future things: Chapter 3
The Design of Future things
Donald A. Norman
This chapter focuses on natural interaction. Most machines now days use one or many signals, either visual or auditory, to communicate back to humans. The amount of signals machines send to us now can at sometimes be overwhelming. It is really easy to get mixed up on what machine is signaling as well. A washer and dryer of the same make often have the exact same auditory sounds in there control system. Yet it is still easy to figure out which one is signaling you due to natural sounds. Why can't more of these natural sounds be incorporated into modern machinery. One popular example of a natural interaction is a tea pot. When the water starts to boil, the tea pot starts to whistle and thus provide a natural auditory feedback to notify the user that the water is boiling. Some designers have even made it to where the tea pot makes a pleasant musical chord from the steam. Natural interaction is something inventors should try to maintain in this modern age. As the auto industry shifts to electric cars, vehicles are becoming more and more quiet. This can be a big problem especially for blind people. Since they rely heavily on sound, not being able to hear a car can be extremely dangerous. Even for the driver, the lack of noise in the car takes away a part of the natural feedback cars use to give us. Machines and users need to complement each other. If they could do this, the interaction would be much more appealing to users and safer overall.
I think natural interaction is a nice thing because it allows communication on a deeper level. Machines that have the ability to communicate with their users on deeper level will be infinitely more useful. Having that natural interaction allows the person to understand their machine a lot better. For example, world war II pilots use to be able to know exactly when their plane was going to stall just based on the whine from the engine. That natural communication gives the pilot an increased sense of control over the airplane. This is similar to how some mechanics can tell what is wrong with a car just by listening to it. These auditory clues, however, are usually only detectable by extremely experienced people. This kind of understanding should be pursued in today machines. People are very good at understanding how to use machines or devices before they even know what they are. It shouldn't be to hard to use this understanding to help facilitate natural interaction between people and machines.
Donald A. Norman
This chapter focuses on natural interaction. Most machines now days use one or many signals, either visual or auditory, to communicate back to humans. The amount of signals machines send to us now can at sometimes be overwhelming. It is really easy to get mixed up on what machine is signaling as well. A washer and dryer of the same make often have the exact same auditory sounds in there control system. Yet it is still easy to figure out which one is signaling you due to natural sounds. Why can't more of these natural sounds be incorporated into modern machinery. One popular example of a natural interaction is a tea pot. When the water starts to boil, the tea pot starts to whistle and thus provide a natural auditory feedback to notify the user that the water is boiling. Some designers have even made it to where the tea pot makes a pleasant musical chord from the steam. Natural interaction is something inventors should try to maintain in this modern age. As the auto industry shifts to electric cars, vehicles are becoming more and more quiet. This can be a big problem especially for blind people. Since they rely heavily on sound, not being able to hear a car can be extremely dangerous. Even for the driver, the lack of noise in the car takes away a part of the natural feedback cars use to give us. Machines and users need to complement each other. If they could do this, the interaction would be much more appealing to users and safer overall.
I think natural interaction is a nice thing because it allows communication on a deeper level. Machines that have the ability to communicate with their users on deeper level will be infinitely more useful. Having that natural interaction allows the person to understand their machine a lot better. For example, world war II pilots use to be able to know exactly when their plane was going to stall just based on the whine from the engine. That natural communication gives the pilot an increased sense of control over the airplane. This is similar to how some mechanics can tell what is wrong with a car just by listening to it. These auditory clues, however, are usually only detectable by extremely experienced people. This kind of understanding should be pursued in today machines. People are very good at understanding how to use machines or devices before they even know what they are. It shouldn't be to hard to use this understanding to help facilitate natural interaction between people and machines.
Tuesday, February 1, 2011
Extreme Programming installed: Chapters 4-6
Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson
User Stories, Acceptance tests, story estimation
These three chapters focus on three really important aspects of extreme programming which are user stories, acceptance tests, and story estimation. A user story is equivalent to a requirement for a program. Basically, the customer specifies an example of a user interaction which is written on a card. It is then the programmers job to make that example come to life in the program. XP breaks down the entire program into various user stories so that the programmers can handle each individual task separately. Acceptance tests are the specifics of each user story. While the story gives an example of the usage, the acceptance test specifies what exactly the program needs to do. In order for a story to be complete, it must satisfy its own acceptance test. Story estimation is when the programmers try and put point value on each story to estimate the difficulty of that specific requirement. Initially, it is usually not very accurate but as the project moves along, the programmers start to get a feel of how difficult the stories are going to be based on the stories they have already done. Story estimation will help to give a time line to the customer with an estimation of the finish date.
Ron Jeffries, Ann Anderson, and Chet Hendrickson
User Stories, Acceptance tests, story estimation
These three chapters focus on three really important aspects of extreme programming which are user stories, acceptance tests, and story estimation. A user story is equivalent to a requirement for a program. Basically, the customer specifies an example of a user interaction which is written on a card. It is then the programmers job to make that example come to life in the program. XP breaks down the entire program into various user stories so that the programmers can handle each individual task separately. Acceptance tests are the specifics of each user story. While the story gives an example of the usage, the acceptance test specifies what exactly the program needs to do. In order for a story to be complete, it must satisfy its own acceptance test. Story estimation is when the programmers try and put point value on each story to estimate the difficulty of that specific requirement. Initially, it is usually not very accurate but as the project moves along, the programmers start to get a feel of how difficult the stories are going to be based on the stories they have already done. Story estimation will help to give a time line to the customer with an estimation of the finish date.
These features of extreme programming are some of my favorite. Having an example of the interaction from the user story allows the programmer to mimic it without having near as much guess work. From the other side, the customer can be extremely specific with the kind of interaction they want when they help approve the user story. Having used this before, it really does help in the overall build of the program. It seemed like the projects are a lot more organized and I feel like I always have a direction to go in. I don't have to figure out what part of the program I need to work on next. I simply just move onto the next user story. Acceptance tests and story estimation go hand in hand with user stories. XP provides benefits to both the customer and the programmers that really isn't matched by other programming methods.
Monday, January 31, 2011
The Design of Future things: Chapter 2
The Design of Future things
Donald A. Norman
This Chapter goes into more depth regarding the relationship between man and machine. When the first machines were created, interaction was purely one way with the human controlling the machine. With the creation of computer and basic AI systems, machines are starting to have a voice of their own. On a low level, appliances will notify you when they have finished their task. On a higher level, some cars will pay attention to their driver and in case the driver is drowsy at the wheel or not paying attention, the car will beep or vibrate in order to wake the driver up or make him pay more attention to the road. The car and driver relationship has come to replace horse and driver however, they still have many similarities. In the future, there will be no need for driver's. The driving of cars will become a hobby just like horse riding is now. The day when people no longer need to drive cars will be the day when machines are smart enough to make informed decisions on a high enough level as humans.
The sooner man can be removed from the machine, the safer they will probably be. In most situations, wrecks are always due to driver error. If cars drove themselves, and perhaps were on a network with all the other cars, death from car crashes most likely disappear. There is always a chance of some possible error, however, machines are much less likely to make an error than humans. It is my belief that once the technology is there, we should get rid of the human driver altogether. People could then just be passengers in a car that drives itself. As machines get smarter and smarter, humans cannot afford to get "dumber". We should always have manual back up systems for machines. Not to do so would be foolish. Assuming that most of these automatic cars would use gps for routing, all it takes is a significant solar flare to take out over 50% of earth's satellites. Then most of our gps systems would be worthless. Humans cannot afford to lose common sense as machines and computers get smarter.
Donald A. Norman
This Chapter goes into more depth regarding the relationship between man and machine. When the first machines were created, interaction was purely one way with the human controlling the machine. With the creation of computer and basic AI systems, machines are starting to have a voice of their own. On a low level, appliances will notify you when they have finished their task. On a higher level, some cars will pay attention to their driver and in case the driver is drowsy at the wheel or not paying attention, the car will beep or vibrate in order to wake the driver up or make him pay more attention to the road. The car and driver relationship has come to replace horse and driver however, they still have many similarities. In the future, there will be no need for driver's. The driving of cars will become a hobby just like horse riding is now. The day when people no longer need to drive cars will be the day when machines are smart enough to make informed decisions on a high enough level as humans.
The sooner man can be removed from the machine, the safer they will probably be. In most situations, wrecks are always due to driver error. If cars drove themselves, and perhaps were on a network with all the other cars, death from car crashes most likely disappear. There is always a chance of some possible error, however, machines are much less likely to make an error than humans. It is my belief that once the technology is there, we should get rid of the human driver altogether. People could then just be passengers in a car that drives itself. As machines get smarter and smarter, humans cannot afford to get "dumber". We should always have manual back up systems for machines. Not to do so would be foolish. Assuming that most of these automatic cars would use gps for routing, all it takes is a significant solar flare to take out over 50% of earth's satellites. Then most of our gps systems would be worthless. Humans cannot afford to lose common sense as machines and computers get smarter.
Tuesday, January 25, 2011
Extreme Programming installed: Chapters 1-3
Extreme Programming installed: Chapters 1-3
Ron Jeffries, Ann Anderson, and Chet Hendrickson
Extreme programming, or XP for short, is a new way to develop software that focuses on improving the relationship between the customer and programmer. XP has three main roles, the customer, the programmer, and the manager, each with their own responsibilities. The customer is the stakeholder. He or they decide what they want to be able to do with their program. They determine the direction and the look of the project. The programmers are responsible for meeting the customers specifications for the program as well as maintaining a steady flow of completed work. The programmer needs to make sure he completes every user story the customer has given to him. The managers responsibility is to make sure the programmers can accomplish their tasks. They also handle all the planning regarding meetings and also handle any personnel issues. The life cycle of an XP project is different than normal one. The customer defines what he wants, the programmer determines the approximate cost of different implementations, the customer then chooses which he wants so that the programmer can get to work on it. An XP project almost requires a customer to be on site, or at least on site most of the time. This is because the interaction between the customer and the programmer is a lot closer. The back in forth interaction between the two is what really sets agile programming apart. XP wouldn't be taking advantage of this aspect if you didn't have a close relationship with your client.
I found these chapters really interesting because at my current job, we use agile development. Even though we don't use XP, the methods we use are extremely similar. Agile methods are becoming more and more popular and that makes this book relevant. Why is this? I could be a trend or maybe people just like the process better. It's not that agile techniques are superior than traditional methods, they just have a lot of appeal for developers. Agile methods do some things really well that the older methods lacked on. However, agile techniques have their own issues. It is so heavily dependent on communication that if there is a snag at all, it could put your program behind. Also, agile methods use an estimation method to determine when the product will be ready, but this estimation can change greatly depending on how quick or slow the user stories can be completed. So you can't say that agile is better than waterfall or vice versa, it really just depends on what suits your company better. If agile allows you to complete projects on time with all the requirements met, why not use it. If it fits your company and your employees, then agile will help your company succeed.
Ron Jeffries, Ann Anderson, and Chet Hendrickson
Extreme programming, or XP for short, is a new way to develop software that focuses on improving the relationship between the customer and programmer. XP has three main roles, the customer, the programmer, and the manager, each with their own responsibilities. The customer is the stakeholder. He or they decide what they want to be able to do with their program. They determine the direction and the look of the project. The programmers are responsible for meeting the customers specifications for the program as well as maintaining a steady flow of completed work. The programmer needs to make sure he completes every user story the customer has given to him. The managers responsibility is to make sure the programmers can accomplish their tasks. They also handle all the planning regarding meetings and also handle any personnel issues. The life cycle of an XP project is different than normal one. The customer defines what he wants, the programmer determines the approximate cost of different implementations, the customer then chooses which he wants so that the programmer can get to work on it. An XP project almost requires a customer to be on site, or at least on site most of the time. This is because the interaction between the customer and the programmer is a lot closer. The back in forth interaction between the two is what really sets agile programming apart. XP wouldn't be taking advantage of this aspect if you didn't have a close relationship with your client.
I found these chapters really interesting because at my current job, we use agile development. Even though we don't use XP, the methods we use are extremely similar. Agile methods are becoming more and more popular and that makes this book relevant. Why is this? I could be a trend or maybe people just like the process better. It's not that agile techniques are superior than traditional methods, they just have a lot of appeal for developers. Agile methods do some things really well that the older methods lacked on. However, agile techniques have their own issues. It is so heavily dependent on communication that if there is a snag at all, it could put your program behind. Also, agile methods use an estimation method to determine when the product will be ready, but this estimation can change greatly depending on how quick or slow the user stories can be completed. So you can't say that agile is better than waterfall or vice versa, it really just depends on what suits your company better. If agile allows you to complete projects on time with all the requirements met, why not use it. If it fits your company and your employees, then agile will help your company succeed.
Monday, January 24, 2011
Design of Future Things: Chapter 1
Title: Design of Future Things
Author: Donald A. Norman
This Chapter focuses on the relationship between machines and humans and the positive and negative aspects based on the complexity of the interaction. Communication between people and machines are completely different. Between people, you can reason, discuss, and have a two way conversation. Between a person and a machine, however, is quite different. While it is true that communication can be two way, it is not considered dialog because it is composed of two monologues. Communication between human's and machine's is constantly being researched and developed for various reasons. Usually, it is for some convenience or possibly even to make something safer. But as the complexity of the interaction increases, there can be some unforeseeable side effects. An example given in the paper of a car that in which the cruise control is set and then forgot about. The reason it was forgotten is because the car automatically speeds up and slows down based on traffic it sees in front of it. Since the traffic was bad, the car was going slow but as soon as the passenger got of the highway and onto the access road, the car started to speed back up to the highway speed. If the driver wasn't paying attention, this could have easily resulted in a wreck. This happens because machines and computers are programmed to think logically. They cannot reason and thus cannot account for all of the variables. That is why researchers are looking into better ways for humans and machines to communicate.
This paper is extremely relevant to the future of the complexity of machines. I have often thought about, from an ethics standpoint, the relationship between man and machine. The liability aspect is an interesting to look at especially from persons standpoint. Some of the luxury cars are now breaking for the driver if he is not paying attention. However, if for some reason the system doesn't stop in time, it is still the driver's fault for rear ending the car in front of him. I don't think I would ever willingly pay for some automated feature that didn't take the liability off of me as the driver. I feel like I would be lulled into a false sense of security and therefore not pay as much attention to driving if i had all of these autonomous features in my vehicle. There are other situations where automation is wonderful but just like all conveniences, there is an upside as well as a downside.
Author: Donald A. Norman
This Chapter focuses on the relationship between machines and humans and the positive and negative aspects based on the complexity of the interaction. Communication between people and machines are completely different. Between people, you can reason, discuss, and have a two way conversation. Between a person and a machine, however, is quite different. While it is true that communication can be two way, it is not considered dialog because it is composed of two monologues. Communication between human's and machine's is constantly being researched and developed for various reasons. Usually, it is for some convenience or possibly even to make something safer. But as the complexity of the interaction increases, there can be some unforeseeable side effects. An example given in the paper of a car that in which the cruise control is set and then forgot about. The reason it was forgotten is because the car automatically speeds up and slows down based on traffic it sees in front of it. Since the traffic was bad, the car was going slow but as soon as the passenger got of the highway and onto the access road, the car started to speed back up to the highway speed. If the driver wasn't paying attention, this could have easily resulted in a wreck. This happens because machines and computers are programmed to think logically. They cannot reason and thus cannot account for all of the variables. That is why researchers are looking into better ways for humans and machines to communicate.
This paper is extremely relevant to the future of the complexity of machines. I have often thought about, from an ethics standpoint, the relationship between man and machine. The liability aspect is an interesting to look at especially from persons standpoint. Some of the luxury cars are now breaking for the driver if he is not paying attention. However, if for some reason the system doesn't stop in time, it is still the driver's fault for rear ending the car in front of him. I don't think I would ever willingly pay for some automated feature that didn't take the liability off of me as the driver. I feel like I would be lulled into a false sense of security and therefore not pay as much attention to driving if i had all of these autonomous features in my vehicle. There are other situations where automation is wonderful but just like all conveniences, there is an upside as well as a downside.
Friday, January 21, 2011
First blog
Hi, my name is Kyle Casey. I'm a senior computer science major at Texas A&M university. After I graduate in May, I plan on going into consulting as a software developer. I'm interested in many facets of computer science, mainly, web development, gaming, and database systems to name a few. I believe i am strong in general coding practices as well as team leadership. My favorite computer science project thus far was in my programming studio class when we got to design a racecar that we could drive or it could drive itself and we raced against are class mates. The main reason this was my favorite was because my team just clicked. My least favorite projects were the machine problems from 313. Other than the pthread assignment, I just could not get interested in the material at all. I think the biggest development within the computer science industry within the last 5 years is parallel computing. By splitting up tasks and working them in parallel, you can exponentially increase performance. I'm not really picky about what style of coding I use as long as it is readable. Nights are usually better for me since I work in the morning and have class during the day.
Subscribe to:
Comments (Atom)