Coding is Like Baking

Let’s talk about cakes and baking. It’s similar to making software. No really! How quickly you can bake a fantastic cake depends on three main factors. Turns out, it’s the same three for software.

In essence, agility is about your ability to respond to change. I can gain a competitive advantage if I can update my software quickly when I see an opportunity in the market. As a software developer, I’m going to work together with other professionals to decide what new features to build at any one time. The important question is, when we’ve agreed on a particular change and realized the cost of delay is significant: how quickly can my team and I make this change?

How quickly can you make a change to your software?

Allow me to answer that question by comparing it with baking. How long does it take to bake a cake? As with software, I think there are three main factors.

The first factor is how complex a cake it is. How many layers? How many kinds of filling? How fancy will the decorations be? Similarly, changes to a piece of software vary in how big and complex they are, and that will affect how long they take.

The second factor is the skill of the baker(s). When you make fancy flowers out of sugar paste how convincing are they? Can you whip cream without it turning into butter? Do you know how to use a thermometer to get perfectly thick and creamy egg custard? If your skills are poor, you might need to throw out your first attempt and make a second batch of custard or cream or flowers, which obviously slows you down. Developing software is similar - skill, experience and knowledge of particular tools all come into play. If your code changes are poorly designed and fail the tests or the code review, that can similarly slow you down.

When baking, the next major factor for how long it will take is the kind of kitchen you’re going to work in. If I’m a contestant on a show like Bake-Off, I will have a sparkling clean workbench and all the gadgets and accessories I could possibly need. Dirty bowls and saucepans vanish as if by magic when the camera is turned the other way. Fantastic mouthwatering creations appear in a very short space of time.

In contrast, if I’m at home, I might need to clear a space on a worktop before I can start. I could waste valuable minutes hunting around for an electric whisk attachment in an overfull drawer. I might belatedly realize my cake tin is too small for the project I have planned or that I set the oven to the wrong temperature. Creating that amazing cake is not going to be as quick and smooth as it could be.

The worst conditions for baking that I’ve experienced were probably in my shared student house at university. Not only were accessories like whisks and cake tins hard to come by, a huge pile of dirty dishes obscured the sink most of the time. After some weeks, we discovered one of the third years had decided his final exams were so important that he had started to leave all his washing up “for the first years to take care of”, as he put it. I hope you don’t have anyone like that on your team!

In the same way, how long it will take you to build a feature will depend on the state of the environment you’re working in. For a software developer, that environment includes not only the build tools and programming language as you would expect, but also the state of the existing code. Is it clean and easy to understand? Is the current design amenable to the planned change? You might need to spend time cleaning up and fixing things before you can start.

There’s also the build and deployment pipeline the team has set up. Are the regression tests quick to execute and generally passing? Is the deployment automated? Can I observe logs and find bugs in production? If that infrastructure is well oiled and running smoothly, it will make a big difference for how soon my software change can be rolled out.

If you want to be really agile, you need to consider how to improve some or all of the factors in this equation. If you want to build complex, valuable features quickly, you need to make sure you have developers with the skills to build them. You also need to invest in the “kitchen” they are working in.

When I consult with different organizations, I often see problems with developer skill and poor development environments. Investment in both can lead to big gains in agility. You want the time to market for a new feature to be dominated by the essential complexity of that feature, not the accidental complexity that comes from poor code quality, testing and deployment automation. Coding is like baking. Working in a mess is not agile!