Why does it have to take so long?

You know the scenario. When, you’re told that the new thing you want your favourite app or website to do will take way longer than you expected.

It’s seems so simple, you think. Just swap the order, or add one new bit of information. What’s the big deal? Why should it take so long and cost so much? Just to do that.

Is it because you have an incompetent programmer*? Or is he trying to rip you off?

Maybe.

But it’s more likely to be you!

The assumption we make is that because something looks simple on the surface that it must be easy to build or change.

This happens when we have no understanding of how a thing works. Especially when that thing is computer software**.

We have a less difficult time grasping whether a physically mechanical thing is easy or hard to build or change. We’re not surprised by how long it takes to respray the car bright green. But mostly, once something’s built in the physical world it cannot be changed. When it can however, our intuition serves as a rough guide to what’s involved.

When it comes to computers and software, we assume that something can be done merely by pressing a few buttons.

At one level of course that’s true. Code is built by pressing one key on the keyboard at a time. But that’s beside the point.

Like art but…

Writing software is a creative process. It’s about creating something that previously did not exist. That is hard. And it takes time.

Unlike art or poetry however, writing software (always) requires clear, logical thought.

Unlike writing a book, missing a semi-colon could easily cause your entire website or app to crash. Often in unforeseen circumstances.

One small tweak can break or subtly change the way something else works.

Any sort of change requires testing to make sure it works. Not just the new thing but anything that could be affected by the new thing. And you often don’t know what could be affected. So you need to re-test the whole thing to ensure everything else still works.

Adding just one new bit of information on the screen, like a person’s gender, might be relatively easy. On the other hand, it could mean having to identify a new source of data, figure out how it works, negotiate commercial terms, write and test a new complex interface, test that it hasn’t broken or changed how everything else works and then deploy the change to the live environment.

It’s impossible to tell as an outsider how hard or easy any type of software change is going to be. It might take an hour. Equally, it could take months.

Sorry, but you don’t have a clue

There’s another reason why it’s really hard for an outsider to guess the effort required to build or change software. Counter-intuitively, it’s nearly always harder and takes longer to build software that looks simple and is easy to use.

10,000 people are working on the Alexa voice assistant. Alexa is virtually invisible. To get it to do something, all we have to do is talk to it. And yet, behind the scenes are millions of lines of computer code that all have to work in perfect synchronicity.

It’s really hard to make something meaningful and yet truly simple to use.

Unlike building a car, it is indeed possible to change or add a new thing in software. But, it’s never safe to assume it will be easy or quick.

So, am I saying you should always assume software will take longer than you expect to build or change?

No. Once in a blue moon it is easier and quicker than anyone could have guessed. Even the programmer is pleasantly surprised. Sometimes. But it’s best to view that as an occasional bonus.

So, what do you do?

If we have no understanding of computers and software it’s tricky but here are some ideas…

First of all, don’t guess. Don’t, make assumptions.

Accept that there is little to no correlation between how easy something is to use and how hard it is to build and change. How easy (or hard) something is to conceive or describe or use, is no indication of how easy (or how hard) it is to bring to life in software.

If you really need a rule a thumb (and most of us do), then you can reckon that the less you see and have to interact with a computer then the more complex it’s likely to be. Don not be deceived by the tiny Alexa Dot – it’s the tip of an iceberg of code, with 10,000 smart people constantly re-shaping it.

Comparing estimates (and results) from different programmers is also fraught with danger. A poor programmer can often build something more quickly than an excellent programmer. This is because poor programmers take short-cuts. They do this by creating technical debt. This means you will have to pay a lot more later.

An excellent programmer will invest the upfront effort that will pay-off later.

A dishonest programmer will also cost you dear.

So, you need to learn to identify excellent (and honest) programmers. And steer clear of dishonest and poor programmers.

Honest and excellent programmers can help propel your cause dramatically, while dishonest and poor programmers can significantly hold you back. The spectrum of possible outcomes ranges from very positive to very negative.

How do you choose?

That is the topic for another day but here are some questions to bear in mind…

Assuming you have no idea how software works and how it gets built then it can help to find someone who does. Listen to others who have used the type of programmers you are thinking of using. What was their experience?

Do their programmers consistently add new features that translate into real business value?

Do they handle downtime and mistakes proactively and honestly? (Surely excellent programmers don’t mess up! Software is so complex, even the best make mistakes sometimes. The difference is that the good guys admit it upfront, apologise and fix it with good grace)

Good luck!

* I am using the term programmer to mean either one person who builds software or a team or a company.

** Alas, we still live in a world where so few understand how computers really work and can’t even code at a basic level.