Rereading Extreme Programming Explained

extreme programming

I’ve been rereading “Extreme programming explained” by Kent Beck, It is quite interesting to go over ideas. I’m sure you could use the basis of the ideas in many industries. You don’t have to take all the ideas just grab those that will work for you. So anyway this is what I took away from it on this reading.


Do things in the best possible way you can. Doing things at lower quality will only bring you technical debt which eventually drowns you. High quality wins trust and its just the right thing to do. Although it may take longer now the alternative is a future of plugging holes in a leaking bodge built ship.

Short Cycles

Try to keep producing regular improvements incrementally. Big bang ‘look at this finished thing’ never seems to turn out quite how you hoped. Its good for your happiness too as it makes everyone feel like they are making progress. You go home happy, happy bunnies do better work and cope better with the really depressing radio news as they go home.


You can always improve stuff ‘refactor’ it in computer speak. It only needs to do ‘a’ ‘b’ ‘c’ now so only build something that can do ‘a’ ‘b’ ‘c’ now. You can always add the ability to do ‘x’ later.

Your trying to build Minimum Viable Product if you try and guess what the requirements for feature ‘y’ will be along time ahead you will probably be wrong which means rewriting ‘y’ anyway. If you build more you have to be careful your not going off on one, you love these new features but the client couldn’t care less.


Testing Testing Testing and automatically. Testing is dull. Automated testing is less dull. If you have a big set of tests that you can run quickly on a project it can save you time and help you sleep. You don’t want to be lying in bed at night worrying about someones website. It just winds you up. It also helps when you refactor as you can tell that your system is still holding together.

Estimate based on prior experience

Not ideal world estimates, maybe when you do that thing or that similar thing again it will be a lot faster, but probably it won’t. Its probably better to use your last experience of doing this thing to estimate how long it will take to do it now. Hopefully you can refine your estimates so that they become slightly more accurate each time you do them.


The best way is the simplest way, you will be able to understand it in six months and so will anyone else working on the system.