When you first start a software project your initial instinct is likely to be that it should be kept small. Just the critical stuff. Nice and lean.
Somewhere along the way, you may stray from your intuition and start to add more features. A billing system here, a little automation there. Like being on a diet, ‘just one more’ never seems to hurt. But it does hurt, and by more than you may think. In this article I want to highlight the true cost of new features and explore why you may not want to add the feature you’re working on.
The true cost of a feature
When you first assess the cost of a new feature you look at how long it takes to develop it. Suppose this is 20 hours for our Candidate Feature. This is a good start, but what about the time to plan, test, integrate, and deploy it? We analysed this across over 100 projects at Vokke and found that this boosts the time by a whopping 43%. Pretty staggering, but it gets worse.
Once the Candidate Feature has been implemented, it needs to be maintained for the lifetime of the software. Many industry estimates place this at 20% of the initial implementation time. This covers defects you may identify later as well as things that may break as you make changes. We’re now 72% higher than our starting estimate.
You decide that the Candidate Feature is still worth it, so you proceed to implement it. Fast forward a few weeks and its time to implement another feature. The mere fact that we implemented the Candidate Feature first means that this second feature will take longer. Why? Because the new feature needs to work with the rest of the software, and the larger that software is the more time it takes to integrate a new feature without breaking anything. This cost can be minimised with good architectural decisions, but it can’t be removed entirely — even if the development overhead can be made negligible it still takes longer to plan new features for larger software. While this cost is incurred when implementing the second feature, it only exists because the first feature was built originally. This is true for every subsequent feature built after our Candidate Feature. We therefore need to assign the cost to the true culprit. This is a hard one to estimate, but that makes it no less real. Even a conservative estimate would increase our running estimate from 72% to 100% — double our starting estimate.
A house built on sand
Suppose that we implement the Candidate Feature and we’re happy. Life is good. What we may have missed is that this feature relies on features that came before it. Suppose that you have a social product with profile pages for users and an image uploader for adding avatars. Our Candidate Feature might be adding some Instagram-style image filters for this uploader.
If it turns out that you were wrong about people wanting profile pages, then every feature you added after this point was a waste of time. This includes our Candidate Feature.
This isn’t a problem if you know for a fact that each feature you’re adding will stay for good. But what if you don’t? If you’re doing something unique or new you almost never know. The often-overlooked truth is that software is simply a set of assumptions where each builds on the next; if you’re wrong about your first assumption, then you’re wrong about the rest automatically.
How bad is this really? Let’s be optimistic and assume that our Candidate Feature has a 20% survival rate when the above is taken into account. This means that if we implement 5 features only 1 will survive. Put another way, if we implement 5 features — each costing 40 hours like our Candidate Feature — we’ll end up with one surviving feature at a cost of 200 hours.
The real risk you’re facing
While this is bad enough, a more troubling issue is that because the cost of changing the core underlying features is so costly (due to the above), most founders won’t do it. Not because it’s a conscious choice, but because facing the reality is so difficult that they prefer to assume their assumptions are correct. Of course people want profile pages — why wouldn’t they?
Enough of the scary stuff — how do you avoid this?
Simple. Keep your software small. Get honest and brutal and only focus on the features that truly add value to your audience. Understand that everything is a hypothesis and gather evidence about it before assuming it’s correct.
Don’t let this scare you. By focusing intensely on the few things that matter you can outpace your competition. After all, one day of effort by you might equal five for another team that isn’t being so selective.
Now go forth and conquer. One little iteration at a time.
