Why your software doesn’t work

Have you ever built some software that turned out not to be very good at what it was supposed to do? You’re not alone. More than half of all software projects end in failure, and I’d bet that plenty more end up as half-baked solutions that work some of the time.

Why are we so bad at this stuff?

Well, I have a theory. And it turns out it’s not really our fault. Sort of.

I got married a while ago, and my wife, Jodie, took my surname. That meant she had to spend ages changing her name with loads of organisations. Her bank, her employer, businesses, and so forth.

It turned out to be a huge pain, because very few of those organisations provided a way to make this kind of change easily. Their software didn’t easily support it.

But why not?

As you’re probably aware, most software developers are male. It’s an unfortunate situation and something we need to work to improve. But that’s the situation we’re in. Consider this train of thought, in the typical developer’s mind:

“People will need to edit their profiles”…“I should make it easy to change your address, in case people move house”…“How often do people change their names? We can probably de-scope that if it won’t fit in the sprint”

And so, newly married women have a problem on their hands. Now I don’t imagine for a moment that our example developer was aware of the relatively common scenario that he missed. It just didn’t occur to him. Worse still, even if we brainstormed for half an hour and tried really hard to think about edge cases, there’s a pretty good chance that changing your name would still end up a low-priority feature, if we even think of it at all.

These are unconscious assumptions. They’re logical leaps that we make without realising it. It’s hard to avoid them, and they’re everywhere. Remember the face recognition software that didn’t work for black people? Unconscious assumption.

How many unconscious assumptions do you suppose are built into software that deals in complex business logic, where the developer only thinks they understand the domain? This problem is everywhere.

But you can’t just tell people “think harder about your assumptions”. The point is that these are assumptions we don’t know we’re making.

So, we need to build testing these assumptions into the fabric of how we deliver software.

That’s the point of agile. It’s the point of demos, and workshops and involving the client at every stage.

But we’re not doing it enough. We need to deliver in ever smaller increments. Build. Deploy. Verify. Build. Deploy. Verify. Over and over until we get it right.

Can’t do that? Can’t get a build in front of your client and have them tell you it works within a reasonable time frame? Then before you build anything else, get yourself into a situation where you can, avoid unconscious assumptions and build software that works.

Jez Halford is a software development consultant helping teams to deliver better software, more frequently. Visit jezhalford.com to find out more.