“Extreme Programming improves a software project in four essential ways; communication, simplicity, feedback, and courage.” Communication is major reasons projects fail, simply due to the lack of open communication between all the involved parties. Simplicity in extreme programming is focusing on using industry best practices and keeping the solutions simply, the best and most complex development projects often made up of many simply solutions that combined create a complex piece of software. “Feedback on functionality and requirements should come from the users, feedback on designs and code should come from other developers, and feedback on satisfying a business need should come from the client. Courage in extreme programming means having the courage to be open and honest while communicating, the courage to scrap bad code and start over, and the courage to “do it right.”
Extreme programming utilizes 12 practices: Planning, Testing, Pair Programming, Simple Designs, Refactoring the Code, Owning the Code Collectively, Continuous Integration, On-Site customer, System Metaphor, Small Releases, Forty-Hour Week and Coding Standards. Many of these practices have already been discussed, but I’ll expand on those not previously covered. Pair Programming utilizes programmers in two-person teams, where one will initially work selected tasks such as design and double-checking algorithms while the other writes code, then they will switch roles so that both focus on design, algorithms and code. This is initially a more time consuming method, but mistakes are caught early and two people are now familiar with system. Refactoring is simply reviewing the code and looking to see if there is possibly a simpler method. Forty-hour work week, is simply that, team members work a standard work week, focus is maintained on the quality instead of how fast it can be completed.
Some sites of interest for continued reading on Extreme Programming:
http://www.agile-process.org/
http://en.wikipedia.org/wiki/Extreme_Programming
http://http//www.jera.com/techinfo/xpfaq.html
http://ootips.org/xp.html
Hey James,
ReplyDeleteThank you for this explanation. This seems interesting and I am glad that you wrote this post! Concerning the Pair Programming: This looks somehow stressful. Both programmers have to be familiar with the code and have to be able to do everything, somehow. Does this mean that the second person is almost redundant? Although it increases the quality of the code, you have to make a trade-off quality against the costs of the second man!?
I have the opinion that a software engineering project, realized by a bunch of people, where all are equal partners and there is no team leader, who is responsible for the success of the project, will be more ineffective than with someone who will manage the project with its progress.
You have made a lot of great points about Extreme Programming. So much money is lost when projects fail and this seems to be a solution for opening up communication, getting feedback, and correcting mistakes. Having team members work a standard 40/hr week makes people happier and that leads to better quality.
ReplyDelete