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.