Software development vs. software delivery

Software development might be the only industry I know where “done” often doesn’t actually mean “done.” Ever heard a programmer proudly pronounce a particular feature “done” or “almost done” when:

• It isn’t live on production
• It hasn’t been deployed
• Nobody else can actually use it

We are all guilty of doing this at one time or another, myself included. Neither are we to blame for it. We’re not lying about the software being done, we simply have a different perspective on it.

There is a gap between how developers like to romanticize their work, and what the work actually is. It’s the difference between software development and software delivery.

Let me explain.

At the core of it, all software developers are addicted to solving puzzles. You have to be, because programming is so hard that otherwise you’d have given up years ago. That dopamine high when you finally get the computer to do what you want after hours of frustration is the only thing that keeps you going long enough for you to learn to get good.

This addiction to puzzles is a good thing in general, since most software problems are a puzzle at their core, but it comes with the unwanted side-effect that developers will often only consider the logical puzzle (the interesting bit) when estimating work — and forget about all the rest of the work that makes the solution useful to end users.

This work includes things like writing tests, reviewing code, checking back with product to make sure the thing we built is actually the thing that was wanted, implementing a roll-out plan, deploying to production etc. It is usually this part that takes the most time.

As a a rough rule of thumb, it takes about three times as much work to integrate a core logical solution into a usable piece of software, and about three times as much work again to take that from “works on my machine” to “works for all users in production”. So in total it’s nine times as much work as the programmer originally estimated.

This work is the difference between “development” and “delivery”.

As developers we tend to be slightly out of focus on where the value is in the work that we do. This misaligned focus is so common and prevalent that it’s even embedded right there in the name we give ourselves for what we do — software developers.

Well, we develop software right?

WRONG.

We deliver software.

Software development is a misnomer as far as anybody who isn’t a developer is concerned. The only thing the business cares about (and correctly so) is delivery of working software. We should really be calling ourselves software deliverers.

This is because delivered, working software is the end product. It’s the only output of a programmer’s work that is useful, and this is what we get paid for. Code that only works on your machine is about as useful as a paperweight in orbit.

Even if it’s deployed, but it doesn’t work on production for some unforeseen reason, it’s still useless. Nobody cares that it was working on your machine. From the business perspective, it represents a sunk cost with absolutely no benefit whatsoever.

Sadly I don’t think we’ll go from calling ourselves “software developers” to “software deliverers” any time soon, particularly because of the rather awkward biblical connotations, but we can try to retrain our focus a little from “puzzle solving” to “problem solving.”

Prioritising the “puzzle solving” part of what we do is a trap because it ignores all the other work that needs to go into delivering usable software that solves a user problem. It creates too much focus on the technical implementation of what needs to be done, without thinking about user needs. It makes it easier to overlook the cost of getting code into production including testing, deployment, design sign-off, user testing and most importantly evaluating whether this software solution really does help someone.

All the value of software is in the delivery. The actual development is a necessary, but relatively small part of that. So as engineers we can give better estimates and have more productive conversations with stakeholders by focusing particularly on the delivery aspect of what we do. This is hard, since you will have to consciously resist the temptation to consider only the logical puzzle.

One thing that can help is a clear definition of done. Remind yourself of this every time you make an estimation.

Most importantly, avoid the temptation to retreat into your coding hole and think “the business simply doesn’t understand my brilliance”. Chances are, they don’t care about your brilliance, and they didn’t hire you for that. The only thing that’s important to them is the finished software that comes out the end and helps them achieve the business goals.

You might find your interactions with stakeholders get a lot easier when you are more ready to see things from their perspective.