Extreme Programming Explained

Extreme Programming Explained by Kent Beck (1999)

xp-explainedI learned about Agile and XP the first time from a talk by Volker Birk. When I first heard it I was astonished. One of the most salient things was the focus on the people. I heard about the waterfall model before that it was very process driven. But in his lecture he emphasized how important the team is.

While I worked as a quality manager I started off with the typical literature and it still focuses a bit on the people but – understandably – more on the process. And I think that a good process works better than a bad one. But in fields of design / craft like software development or graphic design I’m now more convinced that people matter a ton.

While reading books about software development on the ‘management’ side I’ve seen over and over again that people matter. I think it’s one of the truths which are just hard to swallow and therefore some people try to ignore it. Coming up with new methodologies, patterns, etc.

That is, I’d rather have my product developed but a small but great team than by a big but average one. Every time.

It goes against the egalitarian idea of ‘everyone is equal’. But there are just differences. You can expect two people two be equal – and especially not given a skill. I couldn’t just join the olympics team for swimming. And even if I trained as hard as them I have some physical problems (e.g. my funnel chest) which just reduces my breath capacity by 30%.

The last few weeks / months feel like catching up where I left. I thought about buying this book in 2009 and now I finally will read through it.

I think it’s an absolutely beautiful book. It’s full of wisdom. However, most of these practices are adopted – even if just partly, today.

XP designed for a team of 2-10 software devs

In contrast to typical software engineering projects with 250+ people.

“How would you program if you had enough time?”

I love this. It focuses on the idea of quality, craftsman ship and being proud of your product. I think this idea can be applied to any commercial creator activity – writing, graphic design, etc.

The driver of a software project is the customer. If the software doesn’t do what they want it to do, you have failed. Of course, they don’t know exactly what the software should do. That’s why software development is like steering, not like getting the car pointed straight down the road. Our job as programmers is to give the customer a steering wheel and give them feedback about exactly where we are on the road.

Constant feedback, customer-driven and design. I love his absolute statement: If you don’t solve the customer’s problem you have failed.

We will be successful when we have a style that celebrates a consistent set of values that serve both human and commercial needs: communication, simplicity, feedback, and courage.


Early production needs a little explanation. One of the strategies in the planning process is that the team puts the most valuable stories into production as soon as possible. This gives the programmers concrete feedback about the quality of their decisions and development process that never comes until the rubber meets the road. Some programmers have never lived with a system in production. How can they possibly learn to do a better job?

100% agree. People have to see the product even if it’s just some scribbles on paper. Seeing is believing. Showing that something works or doesn’t work is more convincing that almost every argument.

XP says to do a good job (tests, refactoring, communication) of solving today’s job today and trust your ability to add complexity in the future where you need it.

That’s my modus operandi for years and it works superbly well. Especially if you can deliver a solution which is might do less than some other one but will be more cost-effective. Customers love that.

And why not? Most customers aren’t in the software business but in the X business (where X isn’t software). They want their problems solved.

The difference is between playing to win and playing not to lose. Most software development I see is played not to lose. Lots of paper gets written. Lots of meetings are held. Everyone is trying to develop “by the book,” not because it makes any particular sense, but because they want to be able to say at the end that it wasn’t their fault, they were following the process.

I would argue that that’s in inherently cultural issue. A typical blame culture. It’s drives by applying blame instead of taking responsibility. It’s a culture driven by fear.

Work with people’s instincts, not against them—People like winning. People like learning. People like interacting with other people. People like being part of a team. People like being in control. People like being trusted. People like doing a good job. People like having their software work.

This is one of the main insights I took from this book. Work with the people not against them. I think I quoted that later but Kent Beck says that you need to reward the short-term payoff. You have to work with the ‘natural form’.

Some folks really like this about XP, that it celebrates what programmers seem to do when left to their own devices, with just enough control to keep the whole process on track. One quote I remember was, “XP matches observations of programmers in the wild.”


Fortunately, there is a short-term reason to write tests. Programming when you have the tests is more fun than programming when you don’t. You code with so much more confidence.

It doesn’t seem so at first but writing code when you have working tests is beautiful. It’s so much easier. I think Beck wrote this in this book but I can’t remember which one it was. But the basic gist was the the dev got legacy code and wrote the tests first before editing any existing code. I think that approach is pretty awesome. It makes one so much more comfortable writing and editing code.

So you code because if you don’t code, you haven’t done anything. You test because if you don’t test, you don’t know when you are done coding. You listen because if you don’t listen you don’t know what to code or what to test. And you design so you can keep coding and testing and listening indefinitely. That’s it. [This is] called refactoring.


If you don’t have a reasonable place to work, your project won’t be successful. The difference between a good space for the team and a bad space for the team is immediate and dramatic.

I found this rather interesting. I didn’t have a read about the influence of work space on team performance so I can’t add that much value. However, I’ve seen some problems myself and I saw how fast a good team can detoriate if people are separated by simply a door.

Do only the planning you need for the next horizon—At any given level of detail, only plan to the next horizon—that is, the next release, the end of the next iteration. This doesn’t mean that you can’t do long-range planning. You can, just not in great detail. You can cover this release in great detail and cover the next five (proposed) releases with a set of bullet items. Such a sketch will not lose much over trying to plan all six releases in detail


The person responsible for implementing gets to estimate—If the team takes responsibility for getting something done, they get to say how long it will take. If an individual on the team takes responsibility for getting something done, they get to say how long it will take.

Skin in the game.


The next paragraphs are mostly quoted from the book:

Planning Game

  • The goal of the game is to maximize the value of software produced by the team. From the value of the software, you have to deduct the cost of its development, and the risk incurred during development.
  • Story cards: Task description, estimate, story no., …
  • Business & dev working together
  • Explore, Commit, Steer
  • Exploration: Write a story, estimate it (& split it)
  • Commitment: Sort stories by value & risk and then set scope given velocity
  • Steering: Business picks scope (one to three weeks worth) and dev deliver – deadline remains the same but scope can change

Development Strategy

  • CI: No code sits unintegrated for more than a couple of hours. At the end of every development episode, the code is integrated with the latest release and all the tests must run at 100%.
  • Collective Ownership: Collective ownership tends to prevent complex code from entering the system in the first place. If you know that someone else will soon (in a few hours) be looking at what you are writing at the moment, you will think twice before putting in a complexity you can’t immediately justify
  • Pair Programming: In my experience, pair programming is more productive than dividing the work between two programmers and then integrating the results. Pair programming is often a sticking point for folks wanting to adapt XP. All I can say is that you should get good at it, then try an iteration where you pair for all production code and another where you program everything solo. Then you can make your own decision.

Design Strategy

  • The design strategy in XP is to always have the simplest design that runs the current test suite.
  1. Start with a test, so we will know when we are done. We have to do a certain amount of design just to write the test: What are the objects and their visible methods?
  2. Design and implement just enough to get that test running. You will have to design enough of the implementation to get this test and all previous tests running.
  3. Repeat.
  4. If you ever see the chance to make the design simpler, do it.
  • For the first iteration, pick a set of simple, basic stories that you expect will force you to create the whole architecture. Then narrow your horizon and implement the stories in the simplest way that can possibly work. At the end of this exercise you will have your architecture. It may not be the architecture you expected, but then you will have learned something.

Testing Strategy

  • Here’s what XP testing is like. Every time a programmer writes some code, they think it is going to work. So every time they think some code is going to work, they take that confidence out of the ether and turn it into an artifact that goes into the program. The confidence is there for their own use. And because it is there in the program, everyone else can use that confidence, too.
  • You should test things that might break. If code is so simple that it can’t possibly break, and you measure that the code in question doesn’t actually break in practice, then you shouldn’t write a test for it. If I told you to test absolutely everything, pretty soon you would realize that most of the tests you were writing were valueless, and, if you were at all like me, you would stop writing them. “This testing stuff is for the birds.”
  • The programmer-written unit tests always run at 100%. If one of the unit tests is broken, no one on the team has a more important job than fixing the tests.
  • The customers write tests story-by-story. The question they need to ask themselves is, “What would have to be checked before I would be confident that this story was done?” Each scenario they come up with turns into a test, in this case a functional test.

But there are some absolute showstopper that prevent XP from working—big teams, distrustful customers, technology that doesn’t support graceful change

Code Complete

Code Complete by Steve McConnel (2004)

code-completeIntro: I remember buying Code Complete in 2009 – this was before I gone to college. This was one of the books I saw recommended over and over again. Now, 5 years later I want to embark on the journey and read this tome of software construction.

After reading it I can say that it’s still a good book. I think for beginners (< 2 yrs) it’s really valuable. You can pick up some good habits through this book. You can learn things that others learned hard through experience. Definitely worth a look.

For more experienced people there isn’t that much new stuff in it.

The chapter on metaphors was interesting. I never realized how prevalent they were. Since the time of reading the book and writing this article I’ve read some other books who focus more on metaphors but nonetheless interesting. The question is how useful they are. Not in the sense of having a metaphor but in the sense of learning new insights.
So far (Chapter 3) it reads like a programmers guide to talking to managers; which I think is great for beginners into the job world but not that interesting for me personally. I think it has to do that I did quality management for some time so I know about the importance of requirements and uncovering needs and cost of errors in different stages, etc.

Problem description should be in user language

This is a great advice. I like it because it prevents you from jumping to solutions too fast. If you write – we need some PostgreSQL DB with these primary keys, and … – you think in solutions. And often the problem the customer has isn’t the problem you should solve.

5-15 productivity gain of high (Java, Smalltak, VB) over low-level languages relative to C

Not surprised. Interesting is that the gain varies by language. Java is about 2.5 times productive, Smalltalk 6 times and SQL 10 times. It shows to me the strength of Lisp because it allows you easily to build bottom up and thus basically build your own DSL for every problem you encounter.

Interpreted faster than compiled

Also not surprising. It boils down to faster feedback. Some interpreted languages offer a REPL which allows you to get even more timely feedback.

Habits of good programmers

This was a key insight. Good habits make a good programmer. I’ve written about habits ages ago – I sadly don’t have that post anymore. It was about written communication and writing correctly. Back then I talked to friends and some said that they are going to write correctly if they have to. I argued that you’re not going to learn it if you don’t practice – make it a habit. Same thing here.
Most of the stuff in this book wasn’t new to me but I’ve read tons of other books and have some experience in software development. What I noticed while reading the last quarter of the book how great functional programming can be. The author pointed out several problems and pitfalls which are solved if you use functional programming language.

The last interesting fact was:

Average programmer reads less than a book on programming/software development per year

That’s insane. He recommended to read 12 books a year and you will be pretty quickly above average. I know a lot of people read blog posts and online tutorials or stackoverflow. But a book is just different.

All in all, a good book for beginners. I would recommend it to them.

Hacker And Painters

Hackers and Painters by Paul Graham

Hackers_&_PaintersI read this book December 2008 the first time. I don’t remember a ton of it. I wrote one blog post about the book. But I remember that I enjoyed it.

After rereading it I can say that it’s still a great book. One thing I noticed that he talked about a lot of things I later learned through experience. It’s hard to translate some words into wisdom but imho if you can take away one good idea from a book for around $20 it’s a good investment.

Why Nerds are Unpopular

The first essay  has a different vibe. Back then I felt good about hearing that it will be better in the future. But reading it now I feel sad for pg. It sounds horrible what happened in his high school years and I applaud him for opening himself.

In general, people outside some very demanding field don’t realize the extent to which success depends on constant (though often unconscious) effort. For example, most people seem to consider the ability to draw as some kind of innate quality, like being tall. In fact, most people who “can draw” like drawing, and have spent many hours doing it; that’s why they’re good at it.

If you read my posts for a while you probably know that I’ve started to program half-way seriously when I was around 15. Eventually I got pretty good – with around 19. I remember that some people told me that this was my destiny and I was born to program. But I wasn’t really.

When I was younger I began to play the drums. I think I started at 13. When I was 16 some people said I had a natural talent for playing them. When I started I was horrible – just like my programming. But I put a ton of work in it. I played around 2 hours every day at the drum kit, spend time listening to music and played it the beat with my fingers, I read stuff online, etc.

But this investment was small compared to that into programming. When I started half-way seriously at 15 I spent about 1.5 hour per day into programming. This lasted until I was 17. This was the time I switched school. This meant that Monday – Friday I had about 3 hours per day school-related exposure to programming / cs. Furthermore, around 1 hour talking to friends at school, learning or writing code around 2 hours at home and maybe talking another 1 hour on irc. This makes on average 3+2+1+1 = 7 hours a day. This was 3 years, so I spent around 7000 hours engaging to programming.

I would even say that I took longer at the beginning to learn the fundamentals. Or when I first learned Haskell it took forever. I sat there trying to write code to reverse a list (which is super easy). It took me I think about 4 hours. That’s why I like Lisps / functional programming general because you don’t have to be so clever to understand it. It’s pretty simple and less complex imho.

Hackers and Painters

What hackers and painters have in common is that they’re both makers.

I describe the maker as a creator. It’s the same concept, it’s about making something from nothing.

You should figure out programs as you’re writing them, just as writers and painters and architects do. […] It’s unrealistic to expect that the specifications for a program will be perfect. You’re better off if you admit this up front, and write programs in a way that allows specifications to change on the fly.


When it comes to code I behave in a way that would make me eligible for prescription drugs if I approached everyday life the same way. It drives me crazy to see code that’s badly indented, or that uses ugly variable names.

This is something I developed over the years. Aesthetics plays a role for me. I want to look at code and it should already say what it does just by the form of it. This why I like Python because it forces you to at least indent correctly.

What You Can’t Say

Although fashions in ideas tend to arise from different sources than fashions in clothing, the mechanism of their adoption seems much the same. The early adopters will be driven by ambition: self-consciously cool people who want to distinguish themselves from the common herd. As the fashion becomes established they’ll be joined by a second, much larger group, driven by fear. This second group adopt the fashion not because they want to stand out but because they are afraid of standing out.


Taste for Makers

But if your job is to design things, and there is no such thing as beauty, then there is no way to get better at your job. If taste is just personal preference, then everyone’s is already perfect: you like whatever you like, and that’s it.

A relativistic viewpoint becomes more and more prevalent. pg talks about a more objective standard to beauty. I agree and so does most of science. Even something subjective as the beauty of a face is consistent through cultures and people. I don’t know enough about the subject, yet. So take this with an extra grain of salt.

When you’re forced to be simple, you’re forced to face the real problem. When you can’t deliver ornament, you have to deliver substance.


GOOD DESIGN IS TIMELESS. In math, every proof is timeless unless it contains a mistake. So what does Hardy mean when he says there is no permanent place for ugly mathematics? He means the same thing Kelly Johnson did: if something is ugly, it can’t be the best solution. There must be a better one, and eventually someone else will discover it.

Related to this is Occam’s razor. It’s rather funny that you can look at some piece of code and think “that’s looks way too complicated” and you work on it and finally you found that you can make the code easier and in most cases less buggy.

GOOD DESIGN LOOKS EASY. Like great athletes, great designers make it look easy. Mostly this is an illusion. The easy, conversational tone of good writing comes only on the eighth rewrite.

I thought I’ve written about that but I hadn’t. This is a famous concept in Taoism called Wu wei which translates approximately to non-action. However, there are several interpretations of non-action. Here’s a video which explains these as levels:

  • concisely not acting – you observe
  • Patience – you’re not actually doing something actively
  • Flow / Effortlessness – it’s looks easy because the person mastered it
  • Doing without wanting – very spiritual

GOOD DESIGN IS REDESIGN. It’s rare to get things right the first time. Experts expect to throw away some early work. They plan for plans to change.

n.c. – see Borland Software Craftmanship

Nothing is more powerful than a community of talented people working on related problems.


Design and Research

Design doesn’t have to be new, but it has to be good. Research doesn’t have to be good, but it has to be new.

I love this. I will just comment on the design part. Reusing good design is a good idea. If we apply that to software development there are obviously design patterns or better OOP patterns. I know there are some database and architecture patterns but I never looked into it. Definitely something I will look into it in the future.

And yet, making what works for the user doesn’t mean simply making what the user tells you to. Users don’t know what all the choices are, and are often mistaken about what they really want. It’s like being a doctor. You can’t just treat a patient’s symptoms. When a patient tells you his symptoms, you have to figure out what’s actually wrong with him, and treat that.


To get good design you have to get close, and stay close, to your users. You have to calibrate your ideas on actual users constantly.

This is was bad graphic designer often do. They do aesthetics instead of design. Design follows customer requirements in a sense of ‘what the customer needs’.

In the software world, this idea is known as Worse is Better. Actually, there are several ideas mixed together in the concept of Worse is Better, which is why people are still arguing about whether worse is actually better or not. But one of the main ideas in that mix is that if you’re building something new, you should get a prototype in front of users as soon as possible.


Building something by gradually refining a prototype is good for morale because it keeps you engaged. In software, my rule is: always have working code. If you’re writing something you’ll be able to test in an hour, you have the prospect of an immediate reward to motivate you.

I agree and edw519 had an other great way to say this:

I love this example:

  * EnterOrders 08/31/10 edw519

I now have a working program[sic] – Woo hoo! You say you want more features? No problem. Let’s start enhancing it.

Domain-Driven Design

One of my super short reviews on the books I read in my My Way to PHP series.

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

You probably heard of the term Domain-Driven Design or DDD before. domaindrivendesignThis is the book which started it all.

It’s a pattern book in essence. Eric Evans seems very fond of Martin Fowler and you experience it while reading. I liked that he presented the patterns in a well embedded context and didn’t focus too much on being a pattern book. Instead you are reading a story of how to design software.

The book could have been shorter, that is the main insights – in my opinion – are in the first hundred or so pages. The idea that you try to establish a ubiquitous language and design a system near to the business you’re trying to support.

It goes into quite lengthy explanations into some topics which don’t need the explanation. But I never felt that he left me behind – which some writers do.

Nonetheless, I think it’s a good book and worth a read.