Your software may be designed to work. But is it designed to be delivered? That may sound like an odd question (“Why wouldn’t it be?”) but I’ve been involved in plenty of projects where the delivery process (release, operationalisation, etc) is long and laboured. The reason is in the design.

We can design for may different things. Or not. We can design to make software automatically testable… or not, in which case testing may be slow and manual. We can design our software to build quickly… or not. As I mentioned when I wrote about the 10 minute build, if it’s designed to build fast it’s probably designed better. And we can choose to design our software to be easy to deliver… or not.

Designing for delivery is primarily about architecture. Components need to be appropriately independent, so they can be built, tested and released without sucking in everything else. And you need the capability to transition smoothly from one release to the next (and back out). But tooling is also important, because if this is to happen often then the glue between and the mechanics within each step of the delivery process need to be super-efficient.

Without rapid delivery we risk wasting time and effort, and we risk losing trust. If we do it really well, and achieve continuous delivery, then we achieve continuous engagement.  Even if we don’t get that far (initially) we ensure we get the benefits of at least frequent delivery—early delivery of value, frequent feedback, potentially lower overall cost, and the opportunity to make frequent small changes to our plans rather than dramatic, expensive ones.

But none of that happens by accident. The system has be deliberately designed to be delivered, and that means thought in its architecture, software design and tooling.

Photo by stavos