Going Forward Is Leaving Past Behind

Greetings, hypothetical Web app developer. So I wrote this thing. It’s for your eyes only. Your non-Web developer buddy will find my ramblings mostly trivial and nonsensical. But you… you are in for a trip. I think. Ready?

Prologue

It’s hard to part with the past. Things we’ve done, stuff we’ve learned, the experiences we’ve had — they aren’t just mental artifacts. They shape us, define us. Yet, they are also the scars we carry, the cold-sweat nightmares that keep us awake. And thus continues our struggle between embracing and shedding what has been.

In this way, a platform is somewhat like us. If it only embraces its past, it can’t ever evolve. If it only looks into the future, it’s no longer a platform. Striking the balance is a delicate game.

Progress

In order to survive, a platform has to move forward. A tranquil platform is a dead platform.

In particular, the Web platform had been caught napping. It awoke startled, facing the mobile beast that’s eating the world and went: Oh shit.

Turns out, our platform has gotten a bit plump. All those bells and whistles are now just flab in the way of scampering limbs. It’s time to get lean–or be lunch.

What’s worse, we aren’t even in the same league. While we’re still struggling to run without apoplexy, the other guy can fly and shoot lasers. We’re so screwed. Gotta get cranking on those lasers. And start losing weight.

Cost

Losing weight is hard work. Like with anything where we give up our habits, the way we steel ourselves and go through is by thinking of the cost of not changing.

For the platform, the obvious one is the code size, which is really a proxy for the cost of complexity — the engineering and maintenance complexity, to be precise. Making a modern browser is an incredibly large task and adding urgency further skews the triangle to higher costs.

Then there’s this paradoxically-sounding thing:

The less often a feature is used, the more it costs.

This is the opportunity cost. The more complicated the system, the more confused is the reasoning about the next steps. At the limit, you can’t step forward at all — there’s always an artifact from your past in the way, be it the fun extra nested event loop, the thing you thought was cool back then, or the the dead appendages you grew one day, just for the hell of it.

Here’s another way to put it (now with action figures!): You have a platform with features and users. Bob is a user of a feature. The cost of keeping this feature in the platform is evenly distributed among all users.

However, if Bob is the only user of the feature, something weird happens: all the users still pay the costs, but now they’re paying them to fund Bob’s habit.

As other users ask for new capabilities and polish, Bob’s feature slowly sinks to the bottom of priorities. A statistical wash, the code of the feature grows a beard and stops doing laundry. Bad smells and bugs creep in. With the rest of the code base moving on, the likelihood of a fire drill around this forgotten mess only goes up.

Time is finite and you spend non-zero time on every feature. There’s some feature work you’re not doing to keep this Bob-only feature.

At this point, all other users should be strongly motivated to make Bob stop using his feature. Bob’s dragging everyone down.

Budget

These are all pretty obvious thought experiments, I guess. Web platform engineers (aka browser builders) are a limited resource. For you, Web app developers, they are your home improvement budget.

Thus we arrive to the main point of this anecdote: how would you rather have this budget allocated?

The answer likely goes like this (pardon for possibly putting words in your mouth):

I want you bastards to let me build things that are not terrible on mobile. You are moving too slowly and that’s highly annoying. My boss is telling me to build a native app, and I SWEAR I will, if you don’t start moving your goofy ass NOW. You know what? I am leaving now. Hear these footsteps?

I’m holding my breath, hoping you’re just faking those footsteps. And if you are (whew!), it seems fair to assume that you want most of your budget spent on making browser leaner, meaner, and capable of flying while shooting lasers. Not maintaining the old stuff. Which means that we need to get serious about deprecation. And being serious means we need data.

Data

In Blink land, we have a fairly comprehensive usage measuring system. Despite some limitations, it provides a reasonable approximation of how widely a feature is used.

Just knowing how widely it is used isn’t enough. There’s definitely some extra dimensions here. Despite their equally low usage, there’s a difference between a newly-launched feature and a forgotten one. Similarly, something that’s rarely used could be so well-entrenched in some enterprise front-end somewhere that removing it will be met with tortured screams of anguish.

We also need to give you, web developers, clear indicators of our past mistakes. There are plenty of platform features that are frequently used, but we platform peeps can’t look at without a frown. It seemed like a good idea at the time. Then the reality happened. Communicating this frown is sometimes difficult, but necessary to look forward.

Action

Clearly, we have work to do. Arriving at a clear framework of deprecation principles is trial, error, and likely yet more tears. But we know we need it. We’re working on it.

As for you, my dear web developer… I need your help.

Use feature metrics in planning your new work and refactoring. If you see a feature that’s falling behind in statistics, think twice about using/keeping it. Talk to your friends and explain the danger of relying on old, rarely used things.

Don’t be a bob. Don’t let your friends be bobs. Being a bob sucks. Not the actual person named “Bob”, of course. Being that Bob is totally awesome.