I was startled from my reverie by a shout, as this gentleman attempted to clear dawdling tourists such as myself out of his way.
I watched with bemusement but resisted the urge to offer to help—knowing the eye-watering value of Murano glass therein.
He eased the precious cargo over one step at a time. The cart—heavily laden with boxes of fragile glass secured with a flimsy strap—wobbled precariously over every step.
The sun baked the scene in an intense 40 degree furnace, like the one whence the glass came. Bump. Wobble. Heavy breathing. Bump, wobble.
Deliveries here are hard and risky work. Irreplaceable unique craft pieces, one mistake and they’re lost forever.
Too many teams suffer through building software like this: crafting a big batch of artisanal changes. Loading up a big batch to deliver to customers.
many teams suffer through building software like this.
We suffer through risky deployments, fearful that any mis-step may lead to disaster.
We optimise our delivery, each engineer efficiently delivering as much as possible; piling our carts high.
We plan our routes using detailed road maps and follow them religiously, fearful of the consequences of deviating from the route we filed.
Sadly, delivery is an accurate metaphor for many teams’ approach to building software. Software development doesn’t have to be like this. Delivery is a poor metaphor for effective software engineering.
Software is not delivered like packages of pre-made goods. Software is crafted, nurtured, and discovered. Software is grown like a garden. Software is supplied like water or energy. Software is improved through experimentation like knowledge.
Delivery logistics can be optimised for efficiency & throughput. Software needs learning and discovery. Efficient delivery prevents outsized outcomes—efforts to eliminate wasteful deviations from plans limit teams. At very best they’ll achieve only the outcomes they were able to foresee in advance.
Efficient delivery prevents outsized outcomes.
At very best they’ll achieve only the outcomes they were able to foresee in advance.
Deliveries can follow planned routes along road maps. Software development is more like exploring an area with a sat-nav. You have a destination in mind but can adapt your route given unforeseen traffic conditions. You can choose to explore things that pique your interest along the way without losing sight of the goal.
Delivery is risky; if you destroy or lose a package it’s gone forever, you can never get it back. Software change can be made low risk and boring if we’re willing to invest in the technical practices, architecture, and tooling to make it so.
Delivery is done when the package reaches its destination. A software change reaching customers is only the beginning of the learning loop. What was the effect of the change? Did it do what we expected? Is there anything that surprises us in the impact on the rest of our production systems? Is it being used in the way we expected? What have we learned about the needs of our users to inform what we do next? Is it valuable or should we undo the change? What was hard about the change and how do we make it easier to do the next?
Beware the influence of the metaphors we use upon the ways we think and work. The language we use affects how we act. We can do better than delivery.