UPDATED 2022: Ever since Heroku has removed their free tier and made clear they don’t plan to continue to innvoate on their platform, I can’t recommend it. The points of this article still stand, but if you’re looking for a PaaS, I’d recommend checking out render.com
Heroku Ought to be Enough for Anybody
There’s a legend in computing history that Bill Gates once said, “640k ought to be enough for anybody” while describing the RAM limit of the IBM PC at a trade show in 1981.
This quote is often referenced as shortsighted and makes for a perfect snarky Twitter reply. There’s a similarly uncorroborated quote for Thomas Watson, chairman of IBM, stating in 1943, “I believe there’s a world market for maybe 5 computers".
People love to throw around these quotes as examples of poor foresight and as a check on one’s humility towards the unbelievable technological changes that happen in short periods of time. Today’s average user would not be able to get anything done with 640k, which is several orders of magnitude fewer than what you’d find in a ‘stock’ laptop (about 8GB of RAM).
But there may be something to be gleaned from the original quote that supposedly inspired this particular Gates legend. The un-referenced quote, published in InfoWorld in 1985, is as follows:
“When we set the upper limit of PC-DOS at 640K, we thought nobody would ever need that much memory.”
A charitable interpretation is that he believed that PC-DOS would be obsolete long before users encountered this limit. In a 1989 interview, Gates even alludes to this interpretation.
“I have to say that in 1981, making those decisions, I felt like I was providing enough freedom for 10 years. That is, a move from 64k to 640k felt like something that would last a great deal of time.”
What the hell does this have to do with Heroku?
I often feel this dichotomy of interpretations when I recommend Heroku as a platform to build a business on. Whenever I try to tell someone that Heroku ought to be enough for them, they inevitably direct me to a blog post about a company such as DoorDash. They had to migrate from Heroku and I don’t want to have to go through that.
Just like the charitable interpretation of the Gates misquote, I don’t mean that Heroku will necessarily be enough for a business forever. I mean that it will probably be enough for a good deal of time.
The fact is, for the vast majority of businesses, Heroku will handle their traffic just fine for a LONG time and the trade-off it provides to a business in the short term is often the right call to make.
Yes, your business may grow big enough that Heroku no longer makes sense. But it’s likely that when that happens, the trade-off was still the correct one to make, when measured against the effort of performing that ops work yourself.
Right Technology, Right Time
Most developers make hundreds (or thousands) of tiny decisions every day in the products they build. It’s often something small like how to handle some sort of edge case that wasn’t considered by a Product Manager. Or it’s choosing what fake data to use for testing.
But there are a few decisions that have incredible ramifications on an entire organization. Choosing language ecosystems. Making 3rd party library selections. Picking a cloud hosting provider. These decisions impact who the company can hire or might add months of unforeseen work. We do our best, but often one of the strongest tools we have is a set of principles for how our engineering organization makes these choices.
For example, some engineering organizations try to primarily choose “boring” technology. They might explicitly model out how many “innovation tokens” they’re willing to spend and try to budget accordingly. Some companies may choose to heavily favor open source software, since that may make debugging issues or contributing fixes easier. Having these guiding principles helps the organization make consistent decisions and allows it to more effectively scale.
Which brings to me a principle I believe in that seems to often get overlooked:
Make the decision that is correct for the present, even if we KNOW if may be wrong in the future.
Technical Debt by Another Name
I’ve always appreciated the analogy of “debt” used to describe certain technical choices. Like monetary debt, technical debt can be an invaluable tool, when used responsibly. It can help you get your product to market months earlier, at the cost of paying down the interest later. To be clear, choosing to do sloppy work or creating an endless backlog of cleanup TODOs is NOT tech debt. And even when people can agree on a definition, many still use tech debt irresponsibly.
Making a technical choice, like hosting on Heroku, building your product in DarkLang, or using MeteorJS is just more tech debt. It gives you the leverage you need now, at the cost of paying down that debt in the future.
Just like with monetary debt, the most important thing here is to recognize when the debt is no longer providing the leverage that encouraged you to incur it in the first place. If you lose sight of this, you wind up in that pit of despair so many developers have become familiar with at the various organizations they’ve worked at.
This perspective seems most often lost on new members to an organization. They may come in and say “Who the hell made these choices? These were terrible decisions.” While it’s certainly true that their outside perspective may provide the clarity needed to recognize that something needs to change, it often underscores a lack of the principle that I outlined. Most of the time, the people before you made the best decisions they could with the information they had at the time. Often, it’s the case that even in hindsight, they made the best decision they could at the time, even though that decision is no longer correct. Think about this the next time you start a new gig somewhere.
