Debugging Work
The image shows an error report from the Integrated Design Environment (IDE) I use in my projects. Supporting projects written in the R computer language, the IDE is produced by RStudio and is a popular tool for R users.
By custom, the error report is read from bottom to top, matching the metaphor of a ‘stack’ that builds from instruction 1 at the bottom of the image and ends at the top of the stack, where the error occurs.
A good IDE localizes errors, making debugging more efficient. I have had enough experience learning how to find and fix problems in my R projects over the past several years to appreciate the power of localization.
The report shows something wrong with the number of rows in a data.frame, a spreadsheet-like object with rows and columns. Most importantly, the report shows me the location of the abnormal state, highlighting a path through the code chunks. It points to the logic failure at line 210 in the file helper.R. With the failure localized, I often can solve problems identified by the IDE, with no extra help. When I do need expert help, the start of the investigation is clearly defined for my expert.
When the R program stops and the IDE localizes the issue, you still must figure out how to solve the problem. Sometimes, it is easy to find the cause and fix the problem; other times it is harder, taking more time and effort. Nonetheless, knowing where to start the investigation always reduces problem-solving time and effort. Imagine if I experienced failure of a 1000+ line R program with no idea where to start looking! I would spend a lot of time hunting through many lines of code to try to identify the cause. Before I learned how to use the IDE to guide my problem-solving, I would often try to patch some workaround that never fixed the underlying logic failure. Frequently, I would simply give up and ask for expert help, with consequent costs in time and sometimes dollars.
Equipping Work Systems with IDE-style error handling
When it is easy to see problems in operations right when they occur, an operations team can solve many problems themselves, without need for outside experts. Less reliance on experts means shorter time to problem solutions. Importantly, more reliance on the local team increases the team’s skill, knowledge and confidence. The team will be better able to solve the next problem…and there’s always a next problem!
In Kato’s Step Up Model, Step Up 1 builds work standards that define normal, the desired state of production of product or service. In Step Up 2, Kato coaches us to design the work, the workplace, and training so it is easy to detect abnormal. Step up 2 has the same aim as a good IDE’s error handling: localize abnormal in time and space, in a way that is easy for the operations team to see.
Before I learned about Kato’s model, I did not see that an IDE-style error-handling system should be integral to the work system. My experience with the RStudio IDE convinces me that Kato is right to emphasize Step Up 2 and increases my belief that I should help my clients follow Kato’s advice.
