Stealing a poker metaphor, there is an important lesson that senior engineers exercise when working in tech: Knowing when to Hold ’em, Fold ’em, or when to walk (or run!) away.
> You've got to know when to hold 'em,
> know when to fold 'em,
> Know when to walk away,
> know when to run.
> You never count your money
> when you're sittin' at the table.
> There'll be time enough for countin'
> when the dealin's done.
For some reason I think of this song when I think about “folding” on a piece of technology. But how should we know when to adopt new tech, or fold on old tech, or run away?
The “Choose Boring Technology” heuristic is pretty dang good. But you know, things change. What is boring today could be holding your company back tomorrow. Innovating on something today may will turn into legacy code that becomes something boring the rest of the industry.
ThoughtWorks’ Tech Radar also tries to visualize this concept. The Gartner Hype Cycle is another attempt to understand it. But when it comes down to it, the decision to hold/fold/walk/run on any particular technology that your particular team uses is a very contextual decision.
What are some good ways to think about this?
Knowing When To Hold Versus Fold ‘Em
I think holding (continuing to use a working technology in place right now) is underrated! It might sound kind of obvious written down, but generally we should endeavor to keep things running if they work!
Chesterton’s Fence is a classic example of a principle of not replacing something until you understand why it exists.
If you can afford to wait, then simply not chasing shiny things is not a bad strategy. You save resources not rewriting your stuff all the time. Stick to PHP, it is fine.
But what cases would you NOT be in a position where you can hold ’em?
- Your system is actively breaking under load
- Your system is insecure and requires a rewrite to fix
- Your system is providing negative business value due to actual product needs
Always Be Rewriting (Incrementally)
You might think that I’m a fan of Spolsky’s advice to never rewrite.
My take is more subtle: always change the parts while the plane is flying, never stop the world to do the rewrite.
So yes, hold if you can, but if you can’t, continuously evolve your platform.
In reality, incremental rewrites happen all the time!
Check out this talk for some behind the scenes rewrites of some famous architectures. Spolsky’s FogBugz famously wrote their own programming language to rewrite in, which they rewrote!
It is really a function of time. When is it time to rewrite?
Obvious Signs That You Should Fold ‘Em
As mentioned above, my top three reasons to fold a system and get a new hand are:
- Your system is actively breaking under load (with no simple fix in sight)
- Your system is fundamentally insecure and requires a rewrite to fix
- Your system is providing negative business value due to actual product needs
Even with obvious signs, sometimes our egos get in the way, especially if we helped build the system in the first place.
Not Obvious Signs That You Should Fold ‘Em
To me, the most important non-obvious sign that you need to rewrite your app (fold your hand) is when the opportunity cost of not rewriting starts to overshadow your existing customers.
In other words, if there is a certain threshold of customers that you would have captured if you had rewritten that justifies the cost of the rewrite.
This is why it is NOT obvious. You may not be able to even see the customers that are not engaging with you.
Yet, you can’t just throw away your existing product; you don’t want to break your existing happy customers too!
This is kinda a rephrasing of the classic Innovator’s Dilemma. I have to admit, I haven’t actually read this book, but the dilemma is that, even though you build a great product, adding value to it is only small and incremental towards the end of its lifecycle (because it is an S curve).
Your competitors can make a new product, make maximum value while you can’t (and shouldn’t!) bear to give up your golden goose.
The Google Inbox Counter Example?
Do you remember Google Inbox? It was an alternative frontend to Gmail.
Its lifecycle kinda exemplifies the Innovator’s Dilemma arc, except within the same company?
In this specific case, Gmail was the incumbent product. There was a need for a rewrite to get fresh features and customers that would have never bothered to adopt Gmail in its current form. Instead of letting another company eat their lunch, they… made second Gmail.
The really interesting thing to me is how they folded (fold like dough, not like a poker hand, sorry) Inbox features back into Gmail.
I really wonder what it was like internally at the company. Was Inbox cannibalizing Gmail customers? When was Inbox going to get to 100% adoption? Or was it seen as a failed rewrite attempt?
It must have been a tough call.
Knowing When To Walk Away / Run
To be clear, in this analogy, “fold ’em” means you’re rewriting your own code.
When you walk/run away, you are avoiding a particular stack or technology altogether.
But this too requires objectivity if you were heavily invested in the thing that people are walking away from.
What are you going to do if you really love Perl? Or Backbone.js? Or React Java?
I’ll admit: I’ve given up on trying to perfectly predict which technologies will die. Tons of tech in the Java and Javascript world has come and gone. Even Docker is… pivoting to AI?.
I really wish this wasn’t the case.
I wish that, as an industry, we could build things with much longer longevity than your average Javascript framework.
I wish that the fact that a library hasn’t had a release in two years was a sign of maturity, NOT death.
In reality, we have to run from dead tech.
Perhaps AI could change the game here. Maybe in the future we’ll have AI repo maintainers that can keep libraries alive with fixes and releases? And maybe having AI write Perl is fine, if humans never have to look at the code anyway? Maybe AI could make it easier for us to hold on technologies and not be on a perpetual rewrite treadmill.
For now though, knowing when to run away from a piece of tech is a bet just like any other.
Conclusion
Holding is underrated, folding is inevitable, and walking away requires objectivity.
The best time to fold is when you have to (security, scale, business value), but also when the opportunity cost becomes too great.
Of course it is judgement, but the judgement is informed by you thinking about the arcs you have seen before in technology, synthesized with the context you have about your customers and the history of the codebases you work with.
Sometimes you need to take big bets on unproven tech to reap value.
The real key is staying humble, knowing when to let go, and knowing that it isn’t really about being right or wrong, just making the best bets we can.
Comment via email