It can be difficult to understand why, what initially seems like a simple app, can end up taking months to ship. This is because, as more and more features are added to a piece of software, the complexity doesn’t increase incrementally, but exponentially.
And it’s not just non-technical people who make this mistake… professional software engineers are often majorly underestimating what it takes to build a new app, add a new feature to existing code.
Matt Haughy posted a popular tweet earlier this year saying that when he hears developers say “I could build that app in a weekend” he thinks of a flow diagram (shown below) which outlines the logic of when Slack’s app should send a notification to a user.
Credit to Matt Haughey. @mathowie (2017)
As you can see, there is a lot of work to implement such a ‘simple’ feature, and a large portion of it happens before anyone writes any code.
Imagine if Slack had just implemented the notifications feature on-the-fly. Without thinking thoroughly through the problem, it could have easily resulted in something which annoyed their users rather than helped them – this would then have meant even more work to remove and rewrite the functionality (not to mention dealing with the fact that some customers may have moved to one of their competitor’s app).
Bill Gates has said, “Most people overestimate what they can do in one year and underestimate what they can do in ten years.”
I think, in a way, Gates’ quote can be applied to building apps. It’s not hard to see existing software (like Evernote, or Trello for example) and acknowledge that it’s had thousands of hours of development to get where it’s at. But of course, my simple 5-screen app can be built in a few weeks, right? In reality, people will more often underestimate ‘small jobs’, and overestimate some of the larger software projects (or at least, more closely estimate the large jobs)!