Extreme Programming (XP) – shortly revised
Extreme Programming (XP)
XP is part of the Agile concept (see my other weblog entry AGILITY: Extracting some Essentials). You can find many pieces of information about XP, for example thru the URL provided on top of this document. And for sure you have read about it somewhere. My opinion is: XP provides some good ideas. Besides that there are some principles that cannot be transferred to any situation without causing disadvantages. And it is risky to use XP for huge projects. Projects with up to 20 persons per team should be quite OK.
Here are just some few principles of XP.
Update after having passing by 11 years: XP is sort of dead to me. There are even some cases where you do not need to program any more, like when it comes to WordPress Blogs and websites or even web shops (take this blog for example, which runs out of the box without additional effort). Even Search engine optimizations can be done nowadays without having to set up something like the SAP Enterprise Search or a Google Server on your own.
This is a great idea. I really don’t understand people that don’t like unit tests. Some team leaders or above tell they cannot introduce unit testing because it is so time consuming. Well, some advantages seem to be understandable only if the return on investment is generated directly after applying a principle. For that I sometimes wish a technician would have a better understanding of econonimal mechanisms as the mentioned ROI.
My advice: Do unit tests for yourself if your department does not support you with that. Soon you will realize how fast your code develops and at the same time errors will be reduced strongly. You can almost forget about the fear of side effects. Just run your unit tests and know the consequences of a change made. Period (cut short).
Under this subject I could nearly write a book (who knows…). But the most essential thing here is: Avoid doing stuff that is unnecessary. Easy? No, just look at a random choice of projects and most of them will be doomed to fail for this criterion. In one of my projects the developers documented every single class and function module coded within the SAP system. They listed all parameters each one with its description. My question: Why not use the SAP system to look up the meaning of the parameters and even of the classes?
Redundant information is one of the most potential time killers. Firstly you have to do double work. Secondly, the redundant information (e.g. the documentation outside the system) is not synchronized with the original. A source of errors appears.
For me, Pair Programming is not practical or senseful in general. If you love to work with your collegue, then you don’t need XP. Everything goes well by itself. If you don’t like to work close with your teammate, then Pair Programming is the worst thing that can happen to you. Human beings are complex entities. Don’t underestimate the destructive force created by unhappy people.At my company, IT Logic, we do individual implementation when it comes to SEO & SEM.
As with every highly recognized entity passing by at lightspeed a rule of thumb should be to pick the best elements of the concept XP and leave out the rest. For me, Pair Programming is seen as potentially useful in some very few special cases and seen as sort of risky in other situations. The conclusion to draw from this concrete suggestion would be to lead beginners by allowing them personal advice from sophomores or experts, if available. But only for a short period of time and later on in a cold standby-mode.