Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar.

Since DevOps is a broad topic, it can be difficult to determine if a team has enough skills and is doing enough knowledge sharing to keep the Bus Factor low. It can also be difficult for someone interested in learning to know where to start. I thought I’d try to brainstorm some DevOps katas to give people challenges to learn and refine their skills. If you’re worried about your bus factor, challenge less experienced team members to do these katas, imagining the senior team members are unavailable.

Single Line of Code

Goal: Deploy a change that involves a single line of code to production.

Exercise

If you have a non-trivial application, or set of related systems, then the time may vary depending on which line of code you touched. So, here are some common examples to try:

• Change the title of your homepage
• Change a line of code that is only executed once (i.e.: application initialization code)
• Change a single line of code within a potential performance bottleneck
• Change a line of code in your infrastructure automation (e.g., puppet, chef or ansible)

Honing the skill

The corresponding question, “How long does it take to deploy a change that involves a single line of code to production?”, is often attributed to Mary and Tom Poppendieck, authors of Lean Software Development. This makes sense, because a core principal of lean is “eliminate waste”, and minimizing the amount of actual work being performed as part of a change minimizes value-adding activities and exposes wasteful ones.

I do not suggest eliminating safeguards from small changes, but John Allspaw explained in Ops Meta-Metrics that small changes are fundamentally less risky. You should still scrutinize small changes, but beware of processes that excessively scrutinizing a simple change.

Watch for waste

The kata should expose parts of the process that take longer than necessary. Often there is a useful activity surrounded by wasteful overhead.

Code reviews, for example, are a useful activity but are often a magnet for wasteful process overhead. A code review for a trivial change should only take a few minutes, but in some organizations scheduling the code review can take days. Ask yourself:

• Did someone have to schedule a review, or was it pulled from “ready to review” queue?
• Did the developer and reviewer both need to be present, or was the review done via asynchronous communication?
• Are there enough available reviewers to process the queue quickly?
• Were other useful activities (like automated testing or static code analysis) blocked while waiting for a code review?

Similarly, the deployment itself can attract types of waste. Make sure deploying does not involve:

• Manually running repetitive tasks
• Waiting for someone to send you “the deploy commands”
• Or searching documentation for deploy commands
• Firefighting or redeploying because someone forgot a step

The examples above are just a few of the many types of waste you might find. The point is that while honing this kata you should keep (but optimize) any activities that make you more confident in the quality of the software you are releasing, but eliminate any associated overhead.