Category Archives: Developer skills

boat going fast

Twenty Years of eXtreme Programming: Interview

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

extreme programming core cycle

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.

Kent Beck 2015 Lean IT summit
Kent Beck 2015 Lean IT summit


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:boat sinking

Instead of this:speedy military boat

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? 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?

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.

muppets pair programming

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 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:

Poker Programming Challenge

Last week Saturday, 26.April 2014,  a few curious developers gathered together at the Morgan Stanley offices in Budapest to learn about a new type of challenge: Lean Poker.  Everyone was excited and after a short introduction the game started. The croupier was already dealing out cards, collecting responses and measuring points. One thing was missing though: not one program was yet able to respond to any move requests. All of them were just sitting there frozen.

You find the event on this link:

Lean Poker @ Morgan Stanley

Saturday, Apr 26, 2014, 9:00 AM

Morgan Stanley Business Technology Centre
Lechner Ödön fasor 8.

17 retreaters Went

English:Due to the success of the new Lean Poker format we will do one more event this spring. Lean Poker is a continuous delivery and lean startup workshop built around a robot poker tournament. You don’t need to know poker, will teach you in the first half an hour! There is no price for the winner except for a round of beer the other teams may …

Check out this Meetup →


Let’s get back to how it started: What is LeanPoker? It is a workshop for developers to practice and improve coding skills, especially agile development and continuous deployment. Participants are divided into groups and competing with one another using algorithms in different programming languages.

These type of workshops existed before, just they were not as competitive and exciting as Lean Poker. The father of Lean Poker is called Coderetreat, although in itself it is also just a few years old, existing since 2009. Rafael Ördög organized many such events and came to the idea to iterate it further using the poker rules for a poker robot competition. Thus Lean Poker was born in January 2014.

At least 60-70 developers participated in Coderetreats in Budapest already, so it was not difficult to find 13 coding heroes for this event. Only one of the following language was required:

  • C++
  • Go (Under review)
  • Groovy (Under review)
  • Haskell
  • Java
  • JavaScript
  • Perl
  • PHP
  • Python
  • Ruby

Actually not even these programming languages were required, a few participants came just to enjoy the fight and have a great time. A casino for developers and math fans.


I can program in C++, Javascript and PHP, but for this purpose PHP seemed the most comfortable tool I could think of. So Attila, Gergely and I formed the PHP team. Gabor joined later on and we choose the name “AllLean”. (For non poker players this refers to “All in”, a term I will describe later on.)

One “sit and go” looks like above. It means that all the teams grab 1000 USD and start to play.  They play until only one player has any money left. Then the first player gets 5 points and the second best get 3 points. This measurement system leads to a few interesting strategies you will see later on.


  • AllLean: PHP
  • Charlie Firpo: Java
  • Cppoker: C++
  • Grandious: Groovy

Each point in the chart represent a “sit and go”. The point average is deducted to clearly see the differences between the teams. In real life all the programs went up to above 400 points.

Beginning Phase

After seeing the charts starting we realized we have to do something quickly not to loose too many points in the beginning. We posted a basic player and so until 10:47 we took the lead. Basically all other clients were just setting up their coding environment and we had this half an hour to our advantage.

First fight

The Java team “Charlie Firpo” realized, that these minutes meant 30 points already, so they pushed out a simple player. This player was doing “all (money) in” all the time, no matter the cards. Like a blind player, betting all his fortune on the game, even without seeing his cards. Interestingly this tactic was winning, because if all other players just bet a certain amount and then fold, the bluff just wins the game. And they won big time, especially since we pushed in a buggy player. Our player was frozen until around 10:45, they took the lead around 11:05 and were most of the time first until 12:05. We realized our mistake around 11:10 and quickly pushed in a version to simply fold all the time. This player could never win, but it became the second from 11:40 till about 12:12 all the time. Second place means three points, what is much better than loosing all the time and having zero points.

Other teams rise

Finally the Grandious team with Groovy language set up their environment and started to play actively. They had an excellent series from 12:15 till 13:45. Then they saw 2-3 lost games and pushed in something. This new version couldn’t really compete against the other players and they lost quite many games until 14:30.

Social Engineering

Seeing Charlie Firpo getting almost always a second place I figured they do an always folding always second place tactic. Cppoker had quite bad performance at the beginning, so I’ve even tried some social engineering: So I went to the Cppoker team and I explained, that for both teams AllLean and Cppoker would be beneficial, if Cppoker would always fold. Then they would be second half the time with an average of 1.5 points, what was better than their performance until 12:00. And for AllLean it would be good to decrease the folding points of Charlie Firpo from a single folding player three points to a second folding player 1.5. Of course this move is debatable, because to advance among players one needs an algorithm with more two points on average. (Sorry Csaba, if I influenced your team in a wrong direction. I thought you were below one point average. Moreover I admit, that first of all I wanted AllLean to advance against Charlie Firpo.)

This is an important takeaway for me: If I advise anything to any other team, especially if they are not doing so good, it can cause some personal emotions and mistrust. And good performing teams don’t need my advice anyway, so I should better keep them to myself in this case 🙂


At around half past two all language envirnoments were working well, basic algorithms were in place. The real fighting started. Charlie Firpo saw a decline, what was not really a decline, but simply other players getting active. They invented a new routine in a rush, but then a real decilne for them started. Grandious seemlingly choose an always folding algorithm first and then they started to implement new better and better algorithms. Cppoker was also getting better and better. I would not be surprised if they would have won the game, had it been started only around 14:00.

Final struggle

Around 15:30 push came to shove, teams just wanted to win, as many points as possible. Any “always folding” or “always all in” strategies caused a long term decline. For a short time starting around 15:40 we – the AllLean PHP team – tried an always folding tactic. We saw, that all other teams became very agressive and thus a sure three points were above the possible five ( 5/3 = 1.67 I would count, if we would have the same winning strategies). But we knew, that we cannot win with always fold, because another always folding player immediately puts our robot to an 1.5 average, what is way below the remaining player average: 5/2 = 2.5. So we implemented a pointing system with a special shortcut: If we didn’t have pairs or cards above seven average, we fold immediately.


Interestingly team Grandious with the Groovy language caught the wave and in this final half an hour their performance was better than any other team, but they didn’t have enough time left to outperform us.

I wanted to change our basic tactic, but my team members just hushed me down and said that they would rather go have coffee for half an hour, so we cannot make any rushed and buggy changes :). We brought in around 2.1 points on average, what was enough to first catch and then overtake Charlie Firpo. They had serious technical problems around 15:30, what lasted for half an hour.


Winning is clearly not rewarded by the organizers, because it is not winning what really matters. It is the effective learning what matters, what you will do differently afterwards. Answers to these questions became imprinted to our minds, we cannot forget anymore:

  • What does continuous deployment really mean?
  • How can one devise and use a simple algorithm until one comes up with something better?
  • What is the attitude necessary to survive and thrive in a constantly changing environment?

So I personally thank Rafael Ördög (Devill) for taking his time to realize this great competition. I honestly wish this becomes a great championship with international gatherings.

Also thanks for the office and lunch for Morgan Stanley.

For more info on Lean Poker, check

View from the office terrace.

总结 / Summary in Chinese

我们的小组,”AllLean”用PHP语言赢了,但是重要的不是赢输,而更重要的是经验“持续部署”(continuous deployment),各两分钟,以及对其他小组进行的策略。比如,我们经验了“上市时间”的重要性。
我感谢Raffael Ördög为了准备和组织这次活动,并感谢摩根士丹利为我们提供办公室。

Short Summary in English

(if you want to study technical language in Chinese)

We organized a poker computer program challenge. Here we were divided into teams and each team used a different programming language:C++, PHP, Java and Groovy. We constructed programs, that could play poker against each other.
Our team, “AllLean” with the PHP language won, but not winning is what matters. More important is the experience with continuous deployment (each two minutes) and employing strategies against other teams. We experienced how important for example “time to market” can be.
I thank Raffael Ördög for preparing and organizing this event and for Morgan Stanley for the office space.