Making Stuff is Making Stuff

On the television as I type this is a show called "Amazing Wedding Cakes", which is unsurprisingly about cake making. In the current episode a bride has ordered 190 individual single-serving cakes. The team is struggling with a trade-off between doing the work on time and doing the work really well.

We all do that. Software is so very much the same. We simply don't have time to obsess on every detail, but we also can't skimp on essential details. We need to make both radial and linear improvement, but we can't abandon our charter to deliver quality.

This has been a running meme this week, whether one can afford quality and whether skimping quality will help a team go faster.  I've gone on record enough times saying that I don' think you go faster writing poor code, and I echo Uncle Bob Martin in saying that our most significant impediment is the bad code we have to work in.

In the end, the boss was pretty angry about the care that was taken with each of the cakes but the work was done on time with pretty high quality. The customers were delighted.

Of course, while that is a common story, the difference between cakes and software is that cake makers don't have to build all their other cakes by modifying the cake they've just made.  If there is an internal defect in one of the mini-cakes, it won't cause the others to fail and it will not cause failures in all of the cakes they make in the future. Wedding cakes are a one-time thing. Software lasts and accrues changes.

That is not to talk down the cake industry. My wife makes cakes, and I know how much work goes into the structure, flavor, and aesthetics. It's a really cool and really competitive artistic industry.

The point is just that some things are short-term and highly visible, while others are more long-term and mostly invisible. If we treated cakes like a multi-year investment it would be silly, and it is similarly stupid to treat software as a bunch of one-off, short-term projects.