In manufacturing, you likely know the problems to look for; broken threads, misshapen parts, etc..

In software, you may have no idea what kinds of problems you may create by changing code. In this way, practicing jidoka is invaluable. It’s how later developers know what can break, what is broken, and offers wisdom about how to fix bugs without breaking something else.

How? Captured Knowledge.

Each automated test represents knowledge captured from previous engineers about how the system was expected to operate in various scenarios. This is actionable knowledge that all future engineers can make use of. It lets future engineers test their changes and immediately learn what (if anything) has been broken without first needing to learn all the nuisances of the software. It is the period when learning how the software operates that greatly extends engineer ramp up, because too often even simple debugging requires direct use of the application and guessing through which scenarios may invoke the altered code.

Without that captured knowledge, the future engineer has to re-learn everything that was known in the past because the raw code does not capture the nuances of what is expected or required. In this way, the knowledge in the tests acts as a safety net. It’s also knowledge the engineer does not need to fill her brain with by memorizing, because he test can be relied upon to act as an institutional memory.

Actionable Knowledge

This is not documentation for documentations sake. It’s a used and actionable part of the process that cannot be ignored. If you fail a test, the build should fail and block your progress. Unlike an external document, which simply becomes out of date. In some ways, that build break acts as an andon call, alerting you to having missed a standard step (documenting the behavior of your code).

Flexibility Creates Choices (and agility)

By offering the wisdom of all engineers who previously worked on the application, we greatly reduce the learning curve needed for an engineer to become a productive team member. This means that we have much more flexibility in terms of how many add to (or take from) an application.

If we add engineers, the drain on those already on the app will be more modest. The tests provide a safety net which can enable a bit more autonomy win confidence. We can also add more than just a few since the bank of knowledge from which they can draw isn’t limited to the brains and mouths of the senior engineer on the team.

If we remove engineers, we shouldn’t need to lose too much sleep over having them forget their current application. The test bank should go a long way in preserving the most critical information.

By making this investment in our code today, we gain flexibility around where to invest our effort for the biggest wins tomorrow. That is the heart of agility. Pursing our greatest opportunities today in a way that won’t stop us from pursuing better opportunities tomorrow.

Foreshadowing

There is still more to say about how they enable speed. We will look at that next time.