#begin
On a recent business trip I decided to re-read one of the greatest and ground laying software development process books of all time; “Extreme Programming Explained, by Kent Beck”. It’s probably my 4th or 5th read-through but I’ve never actually written some kind of review about it. So I thought; what the heck, let’s do this… I’ll write a bit about the things that stood out for me this time.
Embrace change
So the first and most obvious thing about XP is embracing change. Kent has a lovely analogy for this in the book. He equates XP to learning how to drive (sort of, ofc). Driving is a constant process of ‘pointing the car into the right direction’. You point the car this way, then a little that way and sometimes you will need to change direction entirely. Change is the only constant.
This is very similar in a software context; everything changes… all the time. Requirements change, design changes, the business changes, technology changes, the team changes and members of the team them-self change. Kent says: “Software development is like steering, not like getting the car pointed straight down the road”. And our jobs as programmers, engineers and craftsmen or women is to give the stakeholders of our projects a wheel and provide the feedback needed to do the steering. At its core the driving analogy is related on the four values of XP: communication, simplicity, feedback and courage.
FTW
The next thing I want to highlight is the idea that there is a big difference in “playing to win” and “playing not to loose”. Kent talks about this basketball game in the NBA where one team was so far ahead they started “playing not to loose” and of course, in the end they lost even though there was a huge score gap. The other team was “playing to win”, so there was much more fire in them.
Have you even been part of a project that was managed as if you were playing not to loose? The constant bug fixing and changes requirements that turn the already horrible design upside down. The infinite number of ‘worthless’ meetings you had to attend where you had no business of being in the first place… The endless bureaucracy and ritualistic obligations and commitments to modern or trendy software processes. Doing everything “by the book” and still getting nowhere… I’ve known these kind of projects for sure.
XP is here to help you wipe the floor with the loosing game and start playing for the win. It’s here to radically simplify things and in my opinion does it by reasoning from fundamentals. Taking an approach from first principles is often a good idea when it comes to software. I suppose because we as engineers think in abstractions and the things we do can be constructed from smaller ‘parts’, even when it comes to processes. So the simplification XP brings is easy to understand and yet, hard to master (yes, cliché huh?).
Uncle Bob often quotes a quote (qouteception XD) from the book that goes like this: “XP matches the observations of programmers in the wild”. I think this is so true… it really does. I also think XP matches up pretty nicely with “Programmer Anarchy” by Fred George. If you don’t know him, you’re missing out, and should check out some of his talks. His talks about programmer anarchy and very early talks about the micro-service fad are really great. But to get back to the topic of XP… It neutralizes the worthless management layers from organisations trying to built great software. With XP, the programmers are interacting directly with any stakeholders in the project. It transcends business boundaries like internal and external stakeholders and business hierarchies. I think that’s great because the short feedback loops that XP creates are key in creating great software.
Open, Honest Communication
What I also like about XP is the idea of open and honest communication. Haha, yes.. remember this book was written in 1999 and I guess people ego’s were even back larger then, than they are today. Open communication probably leads to more “psychological safety”, which is the number 1 factor that Google identified for making elite engineering teams. Check out this page for a deep dive. If you work in some toxic work culture where opinions of junior engineers for example are ignored, you’ll probably find yourself trapped in the same kind of problems in each project. I mean, if all you have is a hammer, everything’s a nail, right? Open communication will definitely move a project further ahead. Imagine a world where, code review and pair programmer didn’t exist. If you couldn’t provide feedback on other people’s work; the system would be a mess in no time. So, I’m pretty pleased by the fact that XP emphasizes open, honest communication.
Test Driven Development
A topic inherently bound to XP, is Test Driven Development (TDD). TDD has been, and still is (sadly enough) a rather controversial topic. The whole idea behind TDD is to serve long time interest of every single stakeholder engaged in the project. Tests simply keep a system alive longer. Kent says that, when you start a new software project and write tests right from the beginning you will gain confidence in the code which increases further over time.
He also acknowledges however that we have to fight our human nature and internal short-term selfish reasoning to not write tests. He says, and I quote: “Fortunately there is a short-term reason to write tests. Programming when you have the tests is far more fun than programming when you don’t”.
And I totally agree! When you have a comprehensive test suite you have a lot more fun trying wacky shit. If you make your previous tests pass you are confident the system still functions the way it should. If you don’t have any tests, how would you know? I’ve been in both situations and I prefer the option with a comprehensive test suite over none every single time.
But TDD takes practice, and lots of it. To get good at TDD requires time and you must be willing to invest. The problem however is that practice on the job is often discouraged and thus you will have to practice in your free time on personal project.
For some, this is to much to ask… But for the obsessed (like me, Doh!) this will be easy:D! So role up your sleeves and start coding away on some fringe personal passion project. You’ll be able to lean a lot of great and interesting stuff you wouldn’t normally have the time for in a professional setting.
Simple Design
I couldn’t leave the four rules of simple design out of the review. Why? Well because simplicity is front and center in the book and the four rules are sooo simple, straightforward and in-your-face that you cannot get around them while reading the book. They are:
The right design for software at any given time is the one that:
1: Runs all the tests.
2: Has no duplicated logic. By wary of hidden duplication like parallel class hierarchies.
3: States every intention important to the programmers.
4: Has the fewest possible classes and methods.
How could anyone disagree with this!? Even in the “test are bad, mKay” camp they can’t ignore Kent’s infinite wisdom :D. Kent says that: “every piece of design in the system must justify its existence on these terms”. I like that because it makes the team less likely to accrued tech debt. If you work by these rules, you’ll do some serious pruning to move to a simpler design.
The XP solution
The next thing that stood out to me for some reason this time was the following graph.
I like how the practices are coupled like this rats nest. Interestingly, the technical practices are right in the middle of it. Refactoring, simple design, pair programming and testing are the core of XP yet the outer practices are needed to do them effectively. One cannot do without the other. The best thing of this is the fact that CI and short releases is on here. Remember, it’s 1999, way before the modern DevOps movement where we release every few minutes / hours. CI and short releases in terms of XP means to have release every week or so and integrating every few hours.
I think this diagram is really important still. Teams that say they are agile, and pretend to do Scrum are often missing one or more of the practices in this diagram. Scrum is a direct ripoff from XP, its build on top of the practices you see in the diagram yet how many Scrum teams practice them. Why is TDD still such a controversial topic? According to Martin Fowler, doing ‘Scrum’ without being fully committed to every, and all practices, means you are not doing Scrum… You are doing what he calls flaccid Scrum. The team fails, not the process. I’m not a big fan of Scrum exactly for this reason. There is to much ritualistic behaviour bound to do it properly. Without it, its simply not Scrum but some agile spin-off. I also think that there’s just too much process in Scrum. So much time is essentially lost by all the meetings. Especially when you’re doing the poker nonsense where every single member of the team will have a say. This is stupid, and also pointed out in the XP book by Kent.
The number 1 reason for missed deadlines is the fact that someone estimated a user-story for someone else. The person who’s going to work on the user-story should estimate it himself. Of course you could estimate something collectively but never estimate a user-story without the person who’s going to implement it present.
Collective Ownership
In XP there is this crazy idea that everyone can change any code at any given time. That’s not that crazy anymore nowadays but probably was back then. I suppose there are some limits with security critical code etc. but most of it often accessible to everyone. Nothing at my current job is keeping me from pulling another team’s code, making a change or a bug-fix and opening a pull-request. As a matter of fact, I’ve done just that on numerous occasions. I think this is really great.
Kent has a really nice way of defining collective ownership: “Collective ownership increases your feeling of personal power on a project. On an XP project you are never stuck with someone else’s stupidity. You see something in the way, you get it out of the way. If you choose to live with something for the moment because it’s expedient, that is your business.”
Haha, I like that: `You are never stuck with someone else’s stupidity’. That counts for colleagues being stuck with my, or your stupidity as well! Collective ownership is of course amplified when doing pair programming. When you and your colleague work on the same code, the effort is by the both of you. Both will have to suffer each others stupidity :P.
The core idea of collective ownership is of course to spread knowledge. With XP every nook and cranny of the code is known at least by 2 people, because you’ll be pairing most of the time. This spreading of knowledge will reduce project risk.
Rework
One of the core principles of XP is refactoring. Kent says that: “XP revels in rework”, and here comes the best quote of chapter 17, and agruably the entire book: “A day without refactoring is like a day without sunshine”. Haha, Yeah I feel what he’s saying. I refactor continuously to improve the code I’m working on. Some might think this is stupid because it will make the task at hand go slower. But that’s the short term thinking and selfish reasoning Kent talked about earlier.
An important thing to understand is that refactoring != rework. Refactoring might look like rework to people with a ‘normal’ eye for code. But to an experienced TDD practitioner, refactoring is just 1 step in the development process. Without refactoring, you cannot possibly maintain a clean test suite, let alone a clean production code base.
Kent says that: “design isn’t free”. Whenever you ‘design for tomorrow’ you will put in extra code, that needs extra testing, extra understanding and extra explanation. Remember the rules of simple design!? They go hand and glove with refactoring. You refactor to the most simplest way in order to past the tests. Kent says that sometimes you will put in just this little bit of extra design. So you take on a little bit of design tax as well.
So basically, what Kent describes in the book is when you strive for simplicity with high test coverage you enable the software team to do refactoring at a later point in time. You don’t need to take on this design tax and simple design for today, not for tomorrow.
Productionizing
That’s not even a word! But we all know what it means. The end game to every release cycle is to tie up all the open ends to make the software ready for release. Productisation is a term to evolve some sort of proof of concept to a production ready implementation. It tightens up the feedback loop on a project. This stage also adds some additional tests to prove the system for production. You might add some extra performance tests, stress tests or maybe even go through some sort of certification. Sometime this is referenced as “hardening” the system. Kent says he strongly believes in the motto: “Make it run, make it right, make it fast.” I really like this one! 😀
Kent also says that during this stage the team might find themselves in shorter sprint cycles. I’ve definitely experienced that myself as well. This is not necessarily a bad thing. During this stage of a project you often need to collaborate closer with any teams involved in successful release and deployment. You won’t be spending a lot of time evolving the system, but you will be spending lots of time making sure it ends up into the customers’ hands in the best way possible. So be really weary of adding new features during this stage, You should evaluate whether a change deserves to be in the next release.
20 – 80 Rule
I guess we’ve all head of this rule yet I still think its an important highlight. The 20 – 80 rule, or 80 – 20 rule surfaces in so many facets of life. It means that 20% of improvements will only show up after you have done 80% of the exercises. I mean; How many times have you worked on a project where the first 80% of the requirements were easy to implement, but those last 20% were a total mind fuck!?
I’ve come to recognize that I would postpone the ‘hard’ or difficult user stories to the later stages in the project. This isn’t a great idea because the hard problems are often fundamental to the solution. Imagine developing an RPG but leaving the gearing system until last. You would have to tie the gearing system into like stores, stats, skills and all kinds of other systems. If you would have taken the daunting task of the gearing system in the beginning it would have been able to evolve together with the rest of the systems more organically. This way you might just avoid the 20 – 80 rule issue. So, try to tackle the hard parts early in the project. This way you might be able to game the 80 – 20 rule.
But what has this 20 – 80 rule to do with XP anyway!? Well, Kent poses the following question: “Is XP all or nothing. Do you have to follow these practices to the letter or risk not seeing any improvement”? To which he provides the following answer: “Not at all. You can get significant gains from parts of XP. It’s just that I believe there is much more to be gained when you put all the pieces in place.”
Conclusion
So that concludes my review of Kent Beck’s ground laying work on eXtreme Programming. “Extreme Programming Explained” is a really great book to read, even after 25 years of being released. If you have suffered some failed Scrum projects because they were hijacked by some project manager because they did a 2 day Scrum class, you will respect the content in this book, big time. XP is much more than ‘just talking’. It puts development practices first and foremost. This is something often forgotten in Scrum.
As Kent said in the book: “XP matches the observations of programmers in the wild”. I’d like to think that programmers in the wild are these high skilled professionals who take ownership and accountability of their work. We work our butts of and strive for technical excellence through the technical practices of XP: TDD, refactoring, pair programming, simple design and continuous integration. We collaborate with all stakeholders in a project, including the customers and don’t need intermediaries. Feedback looks must be short!
I would encourage every software professional to read this book. It will give you some much needed insights, some refreshments, about the modern software methodologies we are working with today.
To end this review I want to end with my favorite quote of the book. Remember: “A day without refactoring is like a day without sunshine.”
Thx 🙂
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments