Learning to Code Better with Lean Coding

Lean coding aims to provide insight into the actual coding activity, helping developers to detect that things are not going as expected at the 10 minute-level and enabling them to call for help immediately. Developers can use it to improve their technical skills to become better in writing code.

Fabrice Bernhard, co-founder and CEO of Theodo UK, and Nicolas Boutin, architect-developer and coach at Theodo France, spoke about lean coding at Lean Digital Summit 2018. InfoQ is covering this event with summaries, articles, and Q&As.

Lean coding is our effort to study the way we code scientifically, and using kaizen, identify bottlenecks that will give us insight into how to code better, said Bernhard. We have tried one technique in particular that we call ghost programming, he said.

Bernhard explained how ghost programming works:

The idea is to first write the detailed technical plan of what you plan to code for the next few hours in steps of a few minutes. And then, like racing against your ghost in Mario Kart, to compare the actual execution steps and time spent on each step to the initial plan. This allows discovering strong discrepancies between expectations and reality at the code level which are goldmines of potential improvements.

Using lean coding, Theodo improved their productivity. It also helps their teams to improve their way of working.

InfoQ interviewed Fabrice Bernhard and Nicolas Boutin about lean coding.

InfoQ: What is "lean coding"?

Nicolas Boutin: We were trying to improve our work on a daily basis, solving problems that delayed us the next day. And when we asked ourselves what happened during coding time, we realised it was blurry. No wonder since our most precise problem indicator was in fact the daily burndown chart, so the realisation that there was a problem happened only the next morning.

Inspired by a trip to a lean factory in Japan, we wondered how we could create "andon" indicators at a much more granular level. We realised that if during the design phase before coding we added an expected timeline, we would be able to detect that things were not going as expected at the 10 minute-level and be able to call for help immediately. This enabled two very interesting changes: first the team could react to issues and call for help from more senior team members immediately and not the next day. And at the end of the day we knew exactly where things had gone wrong, tremendously helping us identify where to invest our continuous improvement efforts. We called it lean coding in reference to the lean factory that had inspired us.

Fabrice Bernhard: Lean Coding is one of the areas we have explored at the cross-roads of lean and software development. It is interesting to see that since the agile movement took over, there has been a lot of focus on how to improve development work from a project management or operations point of view, but much less from the coding point of view.

InfoQ: How do you do lean coding?

Boutin: Concretely, this is how I do it:

• At the beginning of the day, I choose the next User Story I'm going to ship.
• Then, I break down the User Story into technical steps which last less than 10 minutes, during what we call the "technical design" step.
• The technical design step can last up to half an hour to prepare for a few hours worth of work.
• And then I start coding: each time I exceed the 10 minute takt time, I have identified a discrepancy between expectations and reality. I can either "andon" for another developer to help me get past the issue, or just record the problem for later analysis.
• At the end of the user story, I take a step back to list all the problems I encountered, identify the root causes and planning small actions to help me succeed the following day.

This is what we call ghost programming at Theodo. We even created an internal digital product to help us in this called Caspr:

• Linked to Trello, the tool we use to do project management, Caspr helps during the technical design step to transform my user story into technical steps which last less than 10 minutes.
• During the coding phase, we created a bash interface so that I can drive steps directly from my IDE.
• When I have a problem during coding, Caspr helps me identify how to solve it, suggesting the standard associated to the gesture and who I should ask for help.
• At the end of the day, I know which coding skills I need to improve first, and the team leader can train me through dojos or pair-programing sessions.

InfoQ: What benefits have you gotten from ghost programming?

Boutin: I was the team leader of a 7-developers team. Five weeks after we started doing ghost programming, we managed to double our productivity; we delivered twice as many features compared to what was expected.

At the same time, I coached people to improve their technical skills by doing dojos and improving the work environment of the project. This way people became better in their work.

Since the approach requires strong discipline, there is still some work needed to ensure easy adoption by further teams. One dimension we are looking at is using the technical design steps to proactively help the developer in their upcoming task using machine learning.

Bernhard: We have seen productivity improvements of up to 2x in teams adopting ghost programming. We showed these results in our presentation Toyota VS Tesla? What Lean can learn from Digital Natives.

But beyond these impressive productivity gains, the real benefit is the learnings for the teams. These learnings are quite broad; some examples include quickly identifying skill gaps in the team that can be addressed through training, addressing problems in the infrastructure that slowed down tests and deployments more than imagined, automating some of the developer's tasks to avoid unnecessary mistakes, and adopting a new way of testing the code.

This is the first time I see coders looking scientifically at the way they code to learn how to code better; the potential of this is enormous.