Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Learning to Code Better with Lean Coding

Learning to Code Better with Lean Coding

Leia em Português

This item in japanese


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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Focused on coding

    by Jay Vercellone,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    At most ~15% of my time is spent coding, while the rest is spent on deploying, researching, solving unexpected dependency issues, infrastructure issues, etc.
    How would lean coding apply to this ~85% of work remaining?

  • Maybe I have the right tool for lean coding

    by Bernd Brecher,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You should check out super productivity. It lets you import Jira Tasks and add sub tasks. Mix this with time tracking, task time estimations and a configurable warning if you exceed your estimated time it should be pretty helpful when adopting lean coding. Also it's 100% free, you got full control over your data and it's open source.
    You check it out here:

  • Re: Focused on coding

    by Daniel Bryant,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've been in situations like this too Jay, and I would recommend taking a look at the general Lean Principles in relation to software development, as I found this useful for addressing "wasteful processes" I was doing, and also helped me think clearer about "pulling" work through the SDLC system.

    We've covered more details on this concept in this piece:

    Having said this, a lot of the issues you've mentioned could be coding related (even CD pipeline definitions and infrastructure in some cases), and so I'm sure there is something to learn from this piece -- I personally found the concept of applying the Andon cord very interesting, and this could help address things like unexpected dependencies etc?

    Best wishes,

    InfoQ News Manager

  • Re: Focused on coding

    by Fabrice Bernhard,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks Jay for the very good question. What we are describing in this article is an experiment in the context of a very stable scrum team that is able to code about 75% of their time.
    To achieve that, there are years of experience on how to address issues that hinder the flow and reduce the time spent coding. To name just a few things we do: we work in one-week long Scrum sprints, cut all features in units of work less than a day long and do lean problem solving every morning if we encounter external dependencies or have delays. We also address deployment and infrastructure issues as part of the ongoing kaizen effort to improve the flow.

    So the answer to your question: doing lean in this context would start by stabilising the flow and making sure you reduce external problems. Disciplined Scrum & lean problem-solving is a good way to get there, but it can still take months. Only once you have a decently stable flow can you apply things like lean coding to aim for exciting new frontiers.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p