Extreme programming (XP)
Despite the ever-growing changes we daily experience, a book (invented around the 15th century) still remains as one of the main sources of information.
Recently, I’ve managed to finish one and would like to share my thoughts here.
The book is called “Extreme programming explained” by Kent Beck, it describes extreme programming as a software-development discipline that organizes people to produce higher-quality software more productively.
Even though the book was initially published in 1999, the things are written there are still quite relevant and I wonder if they ever going to change.
Any software engineer, manager, QA specialist or team lead most probably would find this book quite useful and entertaining.
First thing first you may wonder why the “extreme” in the name or XP how we are used to calling it shortly.
Most of the practices in XP are old as programming, though XP takes these commonsense principles and practices to extreme levels. For instance:
if code reviews are good, then the code should be reviewed all the time by pair-programming
if testing is good, then everybody should test all the time (test-driven development), even the customers by writing functional tests
if design is good then it has to be a part of everybody’s daily business by doing continuous code refactoring
if simplicity is good, then the system should be always left with the simplest design possible that supports its current functionality
if integration testing is important, then the integration tests should run several times a day by continuously integrating the changes
if short iterations are good, then they have to be really short — hours, not weeks and months and years
XP is a lightweight agile methodology suited for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. It promises to reduce project risks, improve responsiveness to business changes, improve productivity, enhance quality and last but not least, add some fun to building software in teams. Quite laughing and sounds too good to be true, but you have to read the book to see if the author is crazy.
Below are a quick summary of practices XP is built upon:
early and continuous feedback from short cycles
incremental planning
reliance on automated tests written by programmers and customers
reliance on oral communications, tests and source code to communicate system structure and intent
reliance on an evolutionary design process that lasts as long as the system lasts
reliance on the close collaboration of programmers with ordinary skills
reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project
To sum up, delivering software is hard, and delivering quality software in time is even harder. To make it work requires the disciplined use of well tested and proven practices. This thought-provoking book on XP by Kent, surely would leave you with a couple of interesting ideas to consider.
