software development

Jidoka and Multi-tasking

I’ve recently done a fair amount of research into the application of lean manufacturing techniques to software development. Its mentioned in a lot of places that the Toyota Production System is based on JIT and Jidoka. (Personally I think Kaizen should fit in here as well, as a governing philosophy.)

Essentially, jidoka means:

  • automatically stopping the line when a defect is detected
  • fixing the defect
  • instituting counter-measures to prevent further defects (implies root-cause analysis)

By instituting these counter-measures in the system immediately, you’re building quality into the system.

In my opinion, jidoka resonates with the ‘Boy-Scout Principle’ (leave it better than when you found it) and the Pragmatic Programmers’ ‘Don’t Live with Broken Windows’.

From my interpretation, jidoka means that when you find a defect in your software development process, you stop it there and then, and fix it. Broadly this would include bugs, ‘bad’ or flawed code, broken builds etc. (Please challenge me on these in the comments, I’m not 100% sure if all of these fit in.)

If I extrapolate a bit, this implies that if I’m doing a code review of one of my report’s work and I find some badly written or designed code, I should immediately pull all the developers in my team off of what they’re doing, fix the bad code, and have a session on why the code is bad and how it should be written in future (the counter-measure).

This is where my difficulty begins. It is now relatively well documented that multitasking causes delays in inefficiencies in the process. I know from personal experience that the context switch involved in changing tasks, at any granularity, is expensive and disruptive.

Then, given that interrupting all the members in my team will cause a major context switch, how do I satisfy the demands of jidoka?

If a bug is reported by the QA team or by an end-user, does the developer (or pair) who originally worked on that feature/code stop what he’s doing right now and fix the bug?

Maybe jidoka is less applicable to software development as it is to manufacturing: how much context is involved in the case of a worker attending an assembly line? (I don’t know, I haven’t worked as one before.)

I am led to another (off-topic) question: in the case of a bug report, which causes less of a context switch:

  • the developer moving to work on the bug right away, while the context of his original work on the code is still fresh at the expense of the context of the current task
  • the developer moving to work on the bug only once his current task is complete, thereby retaining the context of the current task, but losing context of the buggy code

How does one achieve a good balance between satisfying jidoka and disrupting the team as little as possible?

When should the knowledge created by the bug fix be disseminated across the team?

Should teams have a scheduled weekly or fortnightly code review/knowledge dissemination session?