Tuesday, March 22, 2011

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.

No comments:

Post a Comment