Myths and truths about software development
Continuing in my High Level Hints series, the million dollar question from potential clients is often “how much is custom software development going to cost me?” Software is a very typical industry that is also surprisingly easy to misunderstand. They say in the bicycle racing world that while you want to have a strong, light, and cheap bike, you actually can only pick two. The same set of tradeoffs are true when buying engineering time for your product: You want bug-free, quickly delivered, featureful software, but have to make a tradeoff. Here’s some hints to help determine your needs and hopefully make that tradeoff an easier decision for you.
Bug-free vs acceptable bugs
Allowing bugs in your software is often acceptable. Let’s say you want to run a tightly controlled demo for potential investors: You need all of the features you intend to be the core of your product, but you also need it for your meeting next Wednesday. This can be accomplished, though it may only work if you click through it in a certain way. Steve Jobs famously did this with the first iPhone demonstration.
We need this developed yesterday
If you need properly working software in a short time frame, you may need to consider cutting out some features. This approach is part-and-parcel of the Lean Startup approach of launching an MVP quickly to paying customers, then adding in features later as your customers help guide you. A challenge with this technique can be your willingness to delay or cut certain features in an effort to get to market quickly. Your core idea can often be represented by less software than you think.
Show me the features
The final scenario is if you need customer-ready bug-free code AND all of your features implemented. The impact here is clear: it will take more time (and therefore money) to accomplish. This is a hard approach to justify if your market fit isn’t established and you have no customer base, but works well for adding sub-products to existing software portfolios.
Why software projects go over budget
The most common causes for budget overruns are changing functionality, changing scope, and changing designs. A good consultancy will try to let you know the impact of mid-development changes, but in general doing legwork ahead of time to document your expectations of how some darker corners of your product will work will go a long way towards keeping development on schedule.
Looking for more detailed information about timeline, budget, complexity and more? Read The Mythical Man Month: Essays on Software Engineering. My favorite point highlighted in the book is that 9 women can’t make a baby in 1 month. To this point, many people have that expectation of software. Sometimes you can’t throw more developers at a problem to solve it due to communication overhead.