Developing Software is Expensive Because It is Hard
If you have an idea for an app and are looking to get it developed but you have no programming experience yourself, it might be wise to learn a bit about the difficulties of developing software so you can avoid the common pitfalls:
- not getting the app you want,
- paying more than you budgeted,
- not getting your deliverables on time.
There is a reason why software takes a long time to develop, is expensive to make, and often isn’t very good: programming computers is hard!
It’s easy enough to learn the basics of programming. There are only a handful of building blocks and by themselves they are easy to understand. However, knowing how to combine them into a larger application is the real trick and that takes many years to master.
If you’ve never programmed before, or never went beyond the trivial programs you had to write in school, the difficulty of the task may be hard to appreciate. In this article, I’ll try to give some insight into why writing software takes so much effort and why it fails so often, and some tips on how to avoid disappointment.
Software is complex
I see a lot of job postings where clients say: “I’m looking to have a simple app developed”. Great, I have nothing against simple apps but you should realize there is no such thing as a simple program.
The app itself may only have a few screens and be a breeze to use, but the underlying program code definitely won’t be simple. A program consists of many small parts that all have to work together in an intricate fashion. As they grow in number it becomes very difficult to keep track of all these parts and to see how they all fit together.
The human brain simply cannot handle this level of complexity. It is impossible to hold the entirety of a program in your head at once. In fact, it is common to make a change to one part of the program and — without realizing it — break something else in another part.
Good software developers use tools and techniques that help them structure their programs in ways that minimize these issues. This is where hiring an experienced developer pays off. But even for a veteran, complexity remains a significant obstacle.
Software is brittle
Computers do exactly what you tell them to, no more, no less. This means the developer needs to be very specific in the commands he gives the computer, or he’ll get different results than he was expecting (i.e. bugs). Programming is a very delicate and time-consuming art.
All the parts in a program are tightly connected. As I said, a change to one part has consequences for the other parts. A program is like a house of cards; take out the wrong card and the house collapses.
Because everything fits together exactly, a change to one piece means that other pieces may have to be modified too. Of course, those additional changes have an impact of their own.
A change that may appear small – “just move this button to the next screen” – can create ripples that have a huge impact on the underlying code. Large chunks of the code may need to be rewritten to accommodate your changes.
You as the client don’t see this but it is work that needs to happen and you will be paying for it, in time and in money (or bugs).
All change has a cost
The cost of making changes increases over time. Early on in the project, the codebase is still small and changes do not yet have much impact, so they are relatively cheap. If you’re unsure about certain features of your app, this is the best time for experimentation.
However, as time goes on, the codebase grows and grows and with it complexity increases. The code becomes more and more tightly interwoven. A big change in functionality will require large portions of the code to be rewritten.
At this point, even a small change can have adverse effects. The programmer may decide that properly restructuring the code to facilitate this small change it is not worth his time (a deadline may be looming) or the money you’re paying him, so instead he will devise a clever workaround.
Unfortunately, clever workarounds will only make the code more complex and harder to understand. If enough of these workarounds accumulate, the code will become unmaintainable and you will be forced to start all over with a complete rewrite.
So what can you do?
Educate yourself
The more you can do ahead of time, before development starts, the better. Get an iPhone or iPad and play with the popular apps. Read the HIG. Devour Tapworthy. Get the Happy Tapper e-book.
You don’t need to become a developer or UI designer yourself, but at least get some idea of what goes into building an app. This will make it easier for you to talk to and understand your developer.
Decide exactly what app you want before you hire a developer. The better you know what you want, and can explain what you want, the less room there is for misinterpretations and the less need there is for changes while programming is underway.
Write down your wishes. Be specific and complete. A good developer will work with you to round out this specification, but the more you can do by yourself in advance, the more money (and frustration!) you save.
Iterate, iterate, iterate
Even though I just said that you should make your mind up on exactly what you want before programming begins, in practice you will find that things that look good on paper do not always work so well when you actually try them on the phone.
It’s simply impossible to do everything right from the start. Revisions are inevitable. The trick is to prepare for this fact and to be flexible enough to handle these changes.
There is nothing more aggravating for a developer than spending several months on an app only to have the client say: “Yeah, that’s not really how we wanted it,” even though the developer built exactly what was agreed upon.
Avoid this by working in short iterations. Split up the project into milestones that each last no more than a few weeks. After each milestone is complete, re-evaluate the project — are you still getting what you want? – and change course if necessary.
Be available for feedback
In the course of writing the program, the programmer needs make a lot of decisions. Most of the time these concern implementation details that you could care less about, but things always come up that will impact the way the app functions. In other words, they expose design issues.
You need to be prepared to come up with solutions to these problems or the programmer will have to make those decisions for you and you may end up with something you did not want. Reversing such a decision is costly for you and frustrating for the developer.
Having an app developed requires constant interaction between the both of you. You can’t simply hand off a stack of specs and expect the developer to re-emerge a month later from his cave with a finished app in his hand. That’s not how it works!
You will need to put in as least as much effort as the developer. This does not mean you need to micro-manage, but you should be available to deal with design issues. It’s your app, after all.
There is more to it than programming
Of course, the programming is only one part of the app development process. Designing the user interaction experience is at least as important and just as difficult. Designing an attractive visual experience is not small feat either.
Some developers can also handle these design tasks but just because someone is a good programmer, doesn’t mean they are also good interaction designers or graphics artists. Chances are you need to hire an UI designer and a graphics artist in addition to a developer, but that’s a topic for another article.
I hope this article gave you some insight into the difficulties of software development. It’s hard because it’s complex and us humans are operating at the limits of our capacity for dealing with this kind of complexity.
Be prepared and increase your chances of success!

Matthijs Hollemans
Good read. This info is very important for non-tech people who are involved with software development. Thanks!
Love this article, we’re going to make this a must read for future clients!
Very True, bookmarking it for the next client
Pingback: ¿Por qué los proyectos web fallan? | Asier Marqués
good post..its matter of fact..
Im 27 years old and starting uni this year doing Bach of I.T majoring in Software Development and Applications. I have NO previous experience in software development, writing code, etc. This article was an excellent great to read, you kept it in lamens terms, which is sometimes hard to find. Cheers