Extreme Programming
The other day I sat in on a presentation of a new (at least new to me) programming methodology called Extreme Programming. I may not have caught everything the presenter said but it certainly broadened my view of possible ways of programming.
Para-programming - Two programmers per computer
As counter-intuitive and counter-productive as this sounds, some research that assigned the same tasks to a group of individuals and to a group of pairs has shown that…
- The pairs completed the tasks in only 15% more man-hours than the individuals
- The individuals frequently requested additional time,
- The applications developed by pairs always worked unlike those of individuals,
- The solutions created by pairs were a lot more elegant.
Here's how it works: There is always one person "driving" and one "navigating." Benefits of this methodology include:
- Increased focus - no chatting or emailing
- Early detection of mistakes
- Brainstorming
- Less interruptions from outside - it's always easier to walk up to a person working on a computer and just ask a question than it is to interrupt a conversation.
Some companies take this to an extreme and do "promiscuous pairing" - pairs change partners every 90 minutes. There is always one person that stays with the project and one that comes new. Benefits are threefold:
- Shared knowledge - Everyone knows the whole application so there isn't that one person that always deals with such and such problem and when that person is sick, no one knows how to fix it…
- The new person coming to the pair brings what they call "Beginner's Mind" - the ability to see problems in a new way, unbiased by "how things should be."
- The person staying has to bring the new person up to speed and they say that you learn best by teaching…
Story-driven development
- All requests made by client are made into 2-3 sentence stories. E.g. Client needs to be able to log in to the system and see his/her information. Clients should not see each other's information. These stories are quoted in hours and should be doable within 1 week.
- The development cycle is about 1 week, so there is no extremely long specification phase, then development phase, etc. Every week, the client gets to choose as many stories as fit into that week - that way client decides on priorities. In this methodology, at the weekly meeting, there is always something tangible you can show to the client - a story that you completed. Your client always knows what you are working on.
- This helps to stay on track with what the client wants even if he/she is unable to stick with the same idea throughout the process. It allows early detection of "client saying: oh, let's not do it that way but instead this other way." You'll luckily find that out as you are about start working on it, not when the application is done and you hand it over as it is done in the standard development model.
There were many other good things presented, such as Test-driven development which doesn't apply to outside Visual Studio (I think). I have not worked with Visual Studio much until this point, but that's certainly changing so I may post about Test-driven development later.
Leave a Comment