The Feature Tax
Naively you may have thought: “I’m sure that Zef got a lot of pushback on his openness about his ambition to do Jack Shit, so probably this week he’ll walk some of that back.”
Hah! No. I’m going to double down on it. I’m going to make an argument that we all should aspire to do Jack Shit, including engineers.
Why? Because everything we do, every line of code we write, introduces new bugs and more maintenance cost. Today’s “hot sexy feature” is tomorrow’s legacy. Therefore, let’s stop building stuff as much as possible.
That’s it. Thanks for reading my TED talk.
No? Not there yet?
Alright, you asked for it. You’ll get the long version.
So here’s what’s going to happen. I’m going to drop a story on you that is somewhat fictional, but as read it, you’ll realize it’s not all that fictional. Then, we’re going to pivot back to today’s reality. This will be somewhat disorienting at first, but soon you’ll realize how it’s connected. You’ll think “hmm, never thought it that way. But come on, will this post never end, I miss my family.” And then, when you least expect it... KABLAM! We’ll get back to where we started.
I know, I shouldn’t reveal my secrets, but it doesn’t matter. It will work anyway.
Let’s go.
We have an engineer with the conveniently gender-neutral name Siri. Due to oversight of our directive to do Jack Shit, we have asked Siri to develop a feature: the Clicky Button.
“Hey Siri,”
Siri spends two weeks on building the Clicky Button.
Typie, typie, type and... done. A beautifully crafted Clicky Button.
Siri ships the feature.
So, now Siri becomes available again to build Feature 2, right?
Well, kinda-ish.
As it turns out, Siri was put under a little time pressure (by a manager asking “Are you done yet? How about now?” on a daily basis), so the “clickiness” of the button deteriorates slightly over time. Siri now needs to reboot the button every week. That’s no big deal though. It’s just 2 minutes of work. Per button.
Also, in its initial version, support has reported that if you push the button not precisely from the top, but just a little bit from the side, the button doesn’t really click. Some would argue that customers are just using it wrong, but the number of calls that support gets about this becomes a massive time sink. So, ultimately, Siri is asked to please adapt the button to still give a satisfying clicky sound when pushed slightly off center. Not a big deal though, shouldn’t take more than a day.
At some later point the marketing department finds out that while the original color of the button was yellow, it really needs to be orange. It’s just a color change though. It shouldn’t take that much time.
The legal department knocks on Siri’s door. The EU is introducing a new law soon that no longer allows buttons to have sharp edges. This is deemed dangerous, so all buttons need to be rounded by the next month at the latest or we get a 10 billion euro fine. Per button. Plus tax. Alright, no big deal.
A helpful engineer from one of the platform teams stops by. “Hallöchen! We’ve noticed that a lot of people are spending an awful lot of time on building buttons. Also due to ever changing laws, we are spending a lot of time everywhere updating these buttons. So, we’ve decided to build the ultimate Generic Button.” It’s not exactly a one-to-one replacement for our Clicky Button, but with a few tricks we can use it to replace a large part of it. Looks pretty clean in code now too. Nice! “Ah, by the way,” the platform engineer adds, “since you’re now using our Generic Button, you also need to always remain up to date with the version of JS-framework-du-jour that we use. No real issue, shouldn’t take you much time to upgrade that from time to time, but just sayin’.”
Alright, time to get cracking on feature number 2.
Another knock on the door. “Hey Siri, security here.” As it turn out, for a long time whenever a customer pushed a Clicky Button a random door in the office building unlocked. “Classic security issue, you’d be surprised how common this is,” the security person adds. “No worries, here’s how to fix it. But to increase your security awareness for similar issues in the future, please do spend about one hour per month on security training. No big deal, though. Just one hour. Ah, and add us as a reviewer for everything you’re going to push to production. Kthxbye.”
“So, how’s feature 2 coming along? Almost done right?”
This week I was asked what a reasonable amount of time to spend on maintenance work would be.
I had never really thought about it. Maintenance work is hard to quantify and kind of hard to explain, because it’s a mix of so many things.
The best model we were able to come up with is the Tax Model. There’s a tax to be paid for every single feature that your product has. This tax is forever.
Not to be dramatic about it, but this tax shall last for as long as you and that feature both shall live (and possibly beyond — prepare your kids). Some of this tax is fixed (it doesn’t depend on usage, for instance), and some of it scales with use. Some of it can be lowered with the right investment, but it’s always there. What do taxes look like? Ask Siri.
This has implications.
It means that in the purely hypothetical scenario where you have a fixed-size team and you keep adding features, at a certain point in time this team will grind to a halt. The tax rate has become so high that all the team is able to do is pay taxes. Whenever you get this feeling that a team is not delivering much, have a quick looksie at their portfolio and you may notice: yah, that’s a long list.
But no worries, as always, we have options:
- We grow the size of the team proportional to the team’s portfolio size: when we add a feature, we add a person to that team, for instance (or maybe a fraction of a person, but there’s some legal concerns around chopping up people in Europe I hear). Note, I did not say add a person “for a few months for a boost”, but forever. And ever. And ever.
- We keep both the team size and the product portfolio size stable by actively removing features that are not worth the tax, creating capacity for new features.
- We say “f...riendly taxes, YOLO!” and stop paying. For a while things appear fine (and we got a good deal on lipstick). But certain parts of the product become dodgy alleys that are no longer safe to enter, lowering the property value around it over time. Until ultimately the whole product turns into a ghetto. And where did all the people go?
- We keep both the team size and product portfolio stable and don’t do Jack Shit.
As with everything, in reality we always (mostly unconsciously) pick a mix of these four (ok, first three).
I have seen few companies that implement strategy (1), although it seems likely the healthiest one. Amazon may be one example, they seem to spin up new teams for new products quite consistently and are good at maintaining the old stuff until ridiculous-level eternity.
Option (2) is also great, but super rare. Building features is easy, killing them is really hard in reality because there’s always a few customers that use a feature, even though they don’t really warrant the expense. Also people prefer to build things than tear them down.
Option (3) is common, although for those companies that survive this approach, many will have an inflection point where things temporarily shut down until taxes are paid back to a reasonable level to be able to move again.
And (4), well, no spoilers.
Whatever mix of options we go with, here is the thing to realize (let’s consider this your 7 minutes of Tax Awareness Training):
Every feature we build (and keep) has an ongoing, eternal tax.
We are good at looking at building cost, not so good at thinking about the tax that comes from maintaining, fixing, tweaking and adapting it over time. This tax doesn’t come from incompetence (mostly), but is inherent — even if the feature doesn’t ask for change, the world around it does.
This means we shouldn’t take “just add this little feature” too lightly. Even though the effort now may seem small, this is the just the beginning.
Be prepared to pay taxes forever.
And ever.
And ever.
Or... do Jack Shit instead. Which has none of these problems.