The bottleneck of software development

What do you think the one activity is that takes up the most of the time for software developers today?

In a draft of a new book, Amr Elssamadisy presents this hypothetical experiment that allows us to figure this out:

Suppose I was your client, and I asked you and your team to build a software system for me. Your team proceeds to build the software system. It takes you a full year, 12 months, to deliver working, tested software. I then thank the team and take the software and throw it out.

After that, I ask you and your team to rebuild the system. You have the same team, requirements, tools, and software. Basically, nothing has changed. It is the same environment. How long will it take you and your team to build the system this time?

Common answers to this question by developers, many of them with 20+ years of experience, is that it will take between 20% and 70% of the time. I.e. Instead of one year it would take 2,5 – 8,5 months. This is a huge difference!

So, what was the problem the first time, what has changed so much? The difference is that team has learned about the requirements, about each other, about the tools etc.

Thus, learning is the bottleneck of software development.

This insight can be used to better evaluate your work methods. Instead of asking: “Will pair programming slow us down”, a more relevant question is “Will pair programming speed up or slow down our learning?”. Another example: “Will we learn faster if we show the system to our customer every other week or if we show it once a month?”

Keep an eye on the bottleneck!

– Henrik

Pair programming

A very powerful, but one of the most non-intuitive agile practices is pair programming. Before one has tried to get good at this, it seems unbelievable that it is actually is better and more efficient for two people to work side by side on the same problem than having two developers working individually.

If you want to get some inspiration and courage to try pair programming, check out this often referenced scientific study of the topic:

“Abstract: Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.”

There you have it: The extra time of 15% that is spent when pair programming is paid back 15-60 times by reduced test costs, depending on the organization. So, pair programming is profitable, good for quality, increases work morale and builds teams.

So, if you have not done so already, go ahead and try now.

– Henrik