Not every feature needs to scale. It’s a little ironic to have those words coming from me since I’ve spent most of my time making applications scale. My time was spent that way because making sure popular features can handle being used by millions of users is important. Without scaling, the application will crash. Those users will be unable to use the product. All the effort spent in acquiring those users will be wasted.
The need to make sure applications could scale was drilled into me early in my career. Unfortunately, that also meant I missed an important qualifier in the above statement. Popular features need to handle being used by millions of users.
How many ideas are smash hits?
Some features have a high probability for success. Good user research can reveal problems that users desperately need to be solved. Features that solve these problems will do quite well. But some of the most innovative ideas solve problems users don’t realize they have. These are riskier ideas with a high probability of failure. It doesn’t mean they aren’t worthwhile, but it does mean we need to treat their development differently.
The difference between making sure a feature scales and just making a feature work is a huge investment in time. 10 times as much time is not outside the realm of possibility. A one week project could balloon to 10 weeks if it needs to scale.
That’s a lot of time to spend on something that users may not like.
An option here is to ignore scalability entirely at first. Build the features. Find what works. Then make the successful experiment scalable.
Some quick and hypothetical math to illustrate this. Let’s say you have two features, each with a 50% chance of success. We’ll use the above numbers of 1 week to build quickly and 10 weeks to build for scale.
If you made them both scalable, it would take 20 weeks.
If you built both quick, it would take 2 weeks. Rebuild the feature that was successful (+10 weeks) and now you’re at 12 weeks of development. That’s 8 weeks of savings!
50% is also a pretty high success rate for an idea not backed by user research. Let’s bring that down to 25%. We’ll build 4 features now.
To make all 4 features scale, it would take 40 weeks.
To build these 4 feature quickly, it would take 4 weeks. Rebuild the successful feature and now we’re at 14 weeks. That’s 26 weeks of savings!
Now I’ve made all these numbers up to illustrate a point. Real development doesn’t work out this cleanly. However, it is incredibly valuable to discuss this kind of work as a team. Some tasks are going to be slam dunks because the user research shows it. Some tasks are going to be big gambles (with hopefully bigger rewards). Knowing which of those is the case is critical in making sure valuable development time is spent in the most effective way.
I’ve definitely been on the wrong side of this in the past. Spending effort to make sure something can handle millions of users when you’re not even sure if it’ll see 100 users is a waste of time. Not only was the effort unnecessary, but I didn’t even get to see the effects of the decisions I made. There was no feedback because the system never needed to scale. It would have been better for the company, the product, my team, and me if we had just spent that time running more experiments and finding something that users actually wanted.
One last thing if you choose to take this advice:
REBUILD THE FEATURES YOU WANT TO KEEP
All too often this is cut. I once knew a prominent company that had built a prototype in the 1980s and continued to use it in the 2000s. Why rebuild it if it works?
Because not doing so is about as attractive as taking a loan from a loan shark.
Software development isn’t measured in small percentages like 50% or 75%. It’s measured in orders of magnitude: 10x or 100x. My example showed projects where making something scalable takes 10x more time than building something quick. Choosing to NOT rebuild and to attempt to force a quickly built system to scale will end up costing you 10x-100x the amount of time it would have too to rebuild it.
The cost isn’t incurred immediately. It slowly kills you over time in the form of bugs and increased time to build enhancements. This is like owing money to a loan shark and having the principal (and interest payments) grow over time. And you are only allowed to pay off the principal at once. Sounds awful right?
I once had a team that had spent a few days making a small enhancement to a feature. We also spent several more days over the course of a few weeks fixing the bugs with that enhancement. When we rebuilt the feature, that very same enhancement took 30 minutes to build. Something that took over 10 person days to do could have been accomplished in 30 minutes if the feature had been rebuilt sooner.
By all means, choose to build things quickly if it makes sense to do so. But don’t for a second think you can get away with not rebuilding those things. It’ll cost you a lot more in the long run to let that technical debt fester.
Rebuild the feature.
This post was originally published on blog.professorbeekums.com
Top comments (1)
Great advice.