Is Our Application Taking Too Long to Build?

So you’ve come up with a brilliant idea for a  web or mobile application that will run your business more efficiently, give your customers exactly what they want, and put you ahead of your competitors. You do some research to determine that this will be an important advantage for your business, you find a developer and you get started.

The first milestone passes and things are a little behind. The second comes around and you’re noticing serious issues. By the time of the final deadline you’re not even close to having a working system.

You start to call around to friends with experience and other people you’ve heard of who do good work, and you ask them how long it should take to build your application. The responses are even more frustrating. Some say “3 weeks”. Others say “6 months”. A few simply reply “we’re not really sure” or “it depends.”

What is wrong with the development industry?

At this point you’re wondering why it’s so hard to get a straight answer. Isn’t there anyone with enough experience to tell you if your development project is taking longer than it should?

We’ve seen this come up in many different forms. For example one client spent 18 months struggling with various developers who couldn’t quite get their simple application working. When we came in we re-focused the project and had the first users on board 2 months later.

Part of this comes from thinking about the project the right way, and I’ll explain how we did this in a bit. But first you need to understand what software development really is.

It’s not like moving a pile of bricks from one location to another. That depends on basic physical forces like mass, energy, and momentum that have been well understood for many centuries. If you hire someone to move bricks and they get sick, you can easily find someone else to do the same job. That is a simple and well-defined task and anyone who has seen it a few times can tell you exactly how long it will take.

Building a software application is nothing like this. It’s been compared to things like creating a work of art, engineering a bridge, or discovering a scientific breakthrough. Although some software projects resemble those tasks they don’t really capture the essence of software development.

In my experience there is one thing that is very similar to creating new software, and that is creating a new business (or a division or product line). Having done both, I see them as different means to reach similar goals. And the similarities run very deep.

If you ask people how long it will take to start a business you’ll have some people telling you it can be done in a weekend and others telling you it will take 10 years. Sound familiar?

Anyone who has managed a business will not be surprised that there is such a wide range. A business is a complicated interaction between many people. Certain key people will have a large and irreplaceable influence. Their sudden arrival or departure can change everything. It takes a lot of negotiation just to get things running on the first day. Once you do you know that things will constantly be changing. Some of them you prepare for in advance and others you deal with as they come up.

In the same way, a software application is a complicated interaction between a lot of different components and people, some that you control and some that you don’t. You’ll spend a lot of time figuring out and agreeing how these interactions will happen. And then once you reach the goal of launching an application that is just the end of the beginning.

Experience helps but it doesn’t solve everything. Someone who has started a lot of restaurants still can’t say exactly how long it will take to start the next one. There could be unexpected regulatory or weather issues. Or a key supplier might go bankrupt right before the restaurant opens. Their knowledge will help to plan the process but it is even more valuable in dealing with the things that don’t go according to plan, which is inevitable.

No two businesses are identical, no matter how similar they look. And no two software applications are identical. That’s why the time to start a business and the time to build a software application can’t be predicted exactly. It’s also why these tasks are never finished.

This is more than a passing similarity. Businesses and the software they rely on are inseparable, interconnected extensions of the same idea.

They are a collection of rules and processes that add value to people’s lives. They aren’t self-contained. They interact with people outside themselves and can’t exist without those unpredictable, changing interactions. And in both cases you will learn a lot as you implement those processes regardless of how much you know ahead of time.

So how can you plan for that?

This doesn’t mean you can’t plan ahead. It just means you have to avoid false certainty. With a large and complex project like this it is impossible to guarantee every detail ahead of time.

What you can do is plan ahead, decide how far you are willing to adapt to circumstances, and take smaller steps.

Going back to our client, the first thing we did was look at their business strategy and long-term plans to get an idea of what needs the application would be serving. We saw that the technology that they had so far was not a good fit for what they wanted to do right away. Even worse, it would make it too difficult to evolve the business after getting their first customers.

With that new understanding, the next step was to build something useful. Now at this point we could have spent a year or more putting together the perfect embodiment of everything we had talked about. But that would increase their risks at time when their business was already strained by the past delays.

Instead we applied our usual approach. We looked at two key features that would create value for their customers, and left the rest for later. We implemented those in a basic but useful way, and kept the current design with only minor changes even though no one liked it.

By doing that we were able to get the first customers into the system within two months, and spent another month cleaning up minor details to smooth the process. Then we started planning another incremental step. This drew on the next priorities but it also gained considerable value from the feedback of those first customers who pointed out areas where they wanted more and things we had planned that they didn’t actually want.

With a series of these incremental steps, each taking about 3 months to incorporate the feedback and build out the next step of the plans, we had fully built the application within one year and it had its first public launch, receiving plenty of positive feedback.

Most importantly, we would not have reached this goal had we spent that year in secrecy building something that no one could see. We would have missed out on customer feedback that defined some of the most essential elements of the application.

And without that feedback, and with mounting pressure to make the application’s launch a success after that much larger investment, it could have easily degenerated into an endless series of internal arguments and changes with little concrete information to back them.

Like any business, an application needs to be exposed to the real world to prove its value. Building that value can be a task that takes years, even decades.

But there is a smaller step you can take now that will advance your goals. We find that 2 – 4 months is an ideal timeframe to spot an opportunity, come up with a solution, build it, deploy it to customers, and get feedback. And if that feedback changes the plans, as it very often does, then there is not much risk involved because you can make those changes early on.

There is no question that it takes discipline to do this. Even experienced project managers and developers can give in to the pressure to just try a little harder to make things perfect and complete before letting anyone in.

Having seen many software projects, we have experienced both ways. They are both difficult. But the difficulty of taking small, controlled steps is far less painful than the alternative.

So when you ask yourself “how long will this application take to build,” there is no perfect answer. But if you ask instead “what can we do in the next few months to create value” there are a lot of clear, simple, low-risk steps. What better place could there be to start?

Leave a Reply