Why your software doesn’t work
Tags: agile, softwaredevelopment
Published: 2018-01-09 22:03:19

---
title: "Why your software doesn’t work"
published: true
tags: agile,software-development
canonical_url: https://medium.com/@jezhalford/why-your-software-doesnt-work-d73e1afec461
---

![](https://cdn-images-1.medium.com/max/1024/0*xc78vCbnswKf1Yux.jpg)

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](https://www.cio.com/article/3068502/project-management/more-than-half-of-it-projects-still-failing.html) 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&nbsp;time.

Why are we so bad at this&nbsp;stuff?

Well, I have a theory. And it turns out it’s not really our fault. Sort&nbsp;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, business, and so&nbsp;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&nbsp;it.

But why&nbsp;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&nbsp;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. I 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&nbsp;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](https://www.theguardian.com/technology/2017/dec/04/racist-facial-recognition-white-coders-black-people-police)? 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&nbsp;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&nbsp;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&nbsp;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&nbsp;works.

_Jez Halford is a software development consultant helping teams to deliver better software, more frequently. Visit_ [_jezhalford.com_](https://jezhalford.com) _to find out&nbsp;more._