I met eXtreme Programming(XP) in 2001, it was love at first sight. That time I had around ten years of developer experience and I finally something that not only goes beyond coding, but gives remarkably timeless advice.

I was reading the book “XP installed”. How thrilling it was to find real usable methods! Urgent medicament for the partially ill software industry. A machete in the jungle of innovative and conflicting ideas.

I was looking for books about programming and this one was said to be practical. I’ve read it online first and then I ordered it on paper and read it again. That time I had like ten years of development experience and it felt like the writers had at least 20-30 years each, way beyond everything I’ve seen. I couldn’t agree more on certain ponts

• the one who programs it, estimates it
• eXtreme Programing “circle of life” 1 Define story -> 2 Estimate -> 3 Choose value -> 4 Deliver
• well defined user stories
• …

I hereby thank the authors: Ron Jeffries, Ann Anderson, Chet Hendrickson and of course. May they live happily as long as they want together with the first creator of eXtreme Programming, Kent Beck.

Basics

There is a gradient between two extremes:

1. a project that has been done millions of times (for example moving an apartment/office)
2. something that has been never done before (landing on Pluto, creating a new type of submarine, or just creating a computer program with specific new needs)

If your project is near the former, then you don’t need eXtreme Programming(XP), you can stop reading now… If however your challenge is something that was seldom – if ever – done before, it’s worth considering Agile Methodologies like eXtreme Programming as a way of completing it.

Practically all major internet companies like Facebook, Google, Amazon use eXtreme Programming tools each and every day: TDD, fast iterations, user stories, … .

How do you know you need these tools?

You are practially drowning in maintenance and support work and your clients are more and more dissatisfied with it. Developers are leaving, it is difficult to find anyone who can or wants to handle your technical debt for a fair price. You can not hold the speed of the competition.

Your boat looks like this:

Instead of this:

Practically all developers know about SCRUM, but very few know about eXtreme Programming. So to change this I was thinking of an article to commemorate the twentieth anniversary. (Kent Beck says XP eXtreme Programming started in March 1996, you can check the video below. )

Interview with Csaba Szegedi Evosoft Hungary

On a Budapest Agile Meetup I met Csaba Szegedi, who has years of XP experience and he kindly agreed to an interview.

 As far as I know you have years of XP developer experience also with pair programming.  What were your main sources of information regarding XP?
www.extremeprogramming.org. An XP coaching cooperation with Pivotal in London. I’ve read many articles about it.

Let’s start at the beginning, do newcomers to your company know XP?
Usually not.

Would it be an advantage if newcomers would know XP?
Yes, even better if they would have XP work experience.

Newcomers know SCRUM I  guess.
Mostly yes.

Are XP and SCRUM enemies?
No, they work well together.

What are your perceptions of these concepts?
XP is good for Quality
SCRUM for the clear roles and ceremonies
KANBAN for agility (fast reaction times)

Can a project with fixed scope and time limit be agile?
No.

What are the advantages of XP in your company?
Knowledge sharing: with pair programming and changing pairs there are always more than two devs having expert knowledge about a subject.  We have microservices architecture. So a certain team can be expert in a service, but everyone can change it. The experts may review it afterwards.

We have over 80% unit and intergration test coverage and this gives us stability.

Less bugs are introduced into the system. We have little technical debt, low maintenance costs.

Customer pays more in the beginning because two pair programmers deliver less than 200% code, but maintenance work will be much less and easier.

After years of development it is still easy to add new features, our system stayed flexible.

What are the disadvantages of XP?
Short term it can cost time and thus money. If you need to train people they will be less efficient in the beginning.

People don’t know it and they have to get out of their comfort zone to do pair programming for example. Developers are conditioned to work alone and pair programming goes straight aganst this. As engineers we have many introverts so we need communication skills.

With pair programming teams should be ready at the same point in time. Latecomers (after 11:00 for exmple) often cannot start with a pair. Pairs depend on each other during their cooperation.

What complementary skills would you advise for extreme programming development?
Soft skills, assertive communication.

What issues did you have while using eXtreme Programming?
We didn’t have enough ownership earlier. We had an official architecture team that interfered with developer teams. Now it got better we have more freedom now.

Earlier we didn’t have domain knowledge. Our product owner was in Germany. PO was not in the team. This caused some waste. (Picture: I go find up and find out what they need and the rest of U start coding!)

To progress effectively we needed the necessary people on board. Luckily our managers are good partners in this regard.

How do you handle if a customer “always present” starts to micromanage every detail?
We let him sit in the retro part – meeting for reflection after a sprint – and tell him how we feel about this.

Do you measure return on investment in eXtreme Programming?
We do not yet measure ROI on XP. Our project alway had XP, so we don’t know how much it would have cost without it. We have some legacy services written without agile methods and it is quantifiable that these services have higher overall defect/bug count. This we do measure.

Does eXtreme Programming generate more or less code?
XP generates less code. Because of refactoring and pair programming the code will be nicer and nicer.

Can you tell me some more about your pair programming practices, maybe even technical details?
One PC, two monitors, keyboards and mouse. We advise daily pair changes, but sometimes pairs stay together for a feature (one or two weeks).

What would you advise to XP starters?
Start with a coach or someone with XP experience. You will get performing much sooner. For example PIVOTAL coaching was very useful. Read extremeprogramming.org and follow it.

How do you manage support and DEVOPS with these methods?
Unfortunately an urgent error can break the SCRUM sprint, but this happens very rarely.

Our teams take responsibility for the support and maintenance of our software (concept called DEVOPS) and this is also included in the general process. Generally you write readable and good quality code because you never know when you meet it next time.

What additional guidance would you need regading this subject?
How to manage more than 30 people?

Pair programming schooling? What are the good pairings? (Senior – junior, with our without domain knowledge, …) How to get pairs working well?

Going beyond eXtreme Programming how can we improve?
We can advance in feature coverage.

Behaviour Driven Development is a useful concept for us, we started implementing with it. (gerkin, cucumber)

Csaba, thank you for these answers!
You are welcome!

---

End of Interview

I’ve found a great session from Kent Beck about the birth of eXtreme Programming: