This week I’m going to move past Web Services and talk about a word that causes most developers to cringe. There are, in fact, many words that cause developers to cringe. Words such as “testing” and “documentation” are examples. The focus today, however, is on a word that encompasses both of these–“methodology.”
When I sat down at my first development job a few (15) years ago, I received what seemed like an encyclopedia set of documents. Fortunately, I was given one three-inch ream of paper that summarized the key points of the documentation. I was told that this was the process through which all projects within the organization were to be created. This was the METHODOLOGY.
I quickly realized that there were an only a few valuable documents within the massive reams of paper. I also quickly learned why the average project time frame at this company was measured in years rather than days or weeks.
In later years, I added to this experience with methodologies. None of the methodologies I would encounter would match the depth of the first. Training classes would later expose me to more efficient methodologies including RAD (Rapid Application Development) and ASD (Accelerated Systems Development). I’d also get to experience CASE (Computer Aided Systems Engineering), which allowed you to use the computer to create the reams of paper most methodologies could only dream of having you produce.
I will never bash the concept of a methodology, however, I will bash how many methodologies are used. When a project becomes focused on generating documentation and on following a process, then something has been lost. A project must always focus on the results needed to help the end user accomplish their job. If a methodology gets in the way of delivering the solution for the user, then the methodology is flawed. Additionally, if the methodology takes more time to follow than the development of the project, then the methodology may also be flawed.
What is all this leading to? A relatively new methodology has been getting a lot of attention. This methodology is called Extreme Programming (XP).
Is another methodology really needed, or have enough trees and brain cells been spent on the existing methodologies? My first reaction was to cringe at the thought of a new methodology. Seeing that XP had a large number of similarities with RAD/ASD, helped alleviate the concerns. Combining a RAD process with a good communication structure and a means to focus on the end results gives the XP paradigm possibilities.
XP cannot be defined effectively in just a few sentences within a short newsletter. There are just too many gory details in XP to cover it appropriately. There are, however, a few points worth mentioning. I bullet them here:
- I was delighted to see that XP follows an iterative approach similar to a RAD methodology. Keeping meetings short, having lots of end-user interaction, and keeping project phases short and to the point are all features of XP.
- I was also glad to see that XP makes a point of keeping things simple. The simplest solution should always be the one used. In fact, if you find a complex solution already implemented, it is suggested by the methodology that you replace it with a simpler solution. In the long run, this is expected to save time. Additionally, you should avoid adding complexity even if it *might* be beneficial in the future.
(http://www.extremeprogramming.org/rules/simple.html) - Overtime for developers on a project should not be allowed. Ouch. What better way to get extra spending money than to milk the added hours near a deadline? This seemed like a weird point for a methodology to make; however, it is an interesting point. The logic is that overtime only wears you down. In the long run overtime will not save any time. You are better to change scope or deliverables to meet a deadline than to force overtime. The methodology also recommends against hiring additional help to hit a deadline.
(http://www.extremeprogramming.org/rules/overtime.html) - All coding should be done in pairs. This point regarding XP was the hardest to swallow. In an XP process, all coding should be done with two people sitting in front of a single computer. The expectation is that you will end up with just as much code being developed, and the code will be of higher quality because it is a collaborative effort. ( http://www.extremeprogramming.org/rules/pair.html)
The overall focus of Extreme Programming is to streamline the overall analysis and development process while still allowing for high quality solutions. This is a relatively new methodology that is catching favor with more and more people every day. Only time will tell if this approach will succeed. A methodology won’t necessarily make you a better developer; however, it might make the projects you develop better.
Is another methodology really needed? Maybe not; however, XP offers some interesting differences in approaching software development. You might find that there are a few features worth incorporating into your own methodology. Now that projects are to be delivered in days instead of years, XP programming is poised to help.
– Brad!
If you have used XP and would like to write a case study on how it worked and didn’t work, I will consider posting it on Developer.com. For more details on the guts and glory of Extreme Programming, here are a few URLs:
http://www.extremeprogramming.org/
http://www.ootips.org/xp.html
http://www.xprogramming.com/
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
There are a lot of other rules and practices for XP. These are listed at http://www.extremeprogramming.org/rules.html
