Deleting 50k Lines of Code in 3 Days

Isn't this exactly why, feature creep? It's not a fair argument, no more fair than 'it's only used by 0.1% of pageviews'. Neither is the full story.

If there's another way to accomplish the same thing, remove the more complex one. If the feature is part of a process that can be done another way, remove it. If the feature is used by an actual 0.1% of users, the impact of removing it is small.

Anyway, I had a friend in the bad old days, had a bulletin board (a bank of phones connected to modems that connected to a bank of computers) that hosted around 300 games. Folks would log in, play a game or two, log out.

He checked; only 10 games ever got played, pretty much. So he started removing most of the rest.

Callers declined 80% in the first week. Disaster; they paid by the minute.

See, folks were browsing his games, the most on any bulletin board! That's why they came to him, to see all that.

Then, sure, they'd play the same popular games nearly every time. But they had to see the other ones there to feel like it was the right place to go.

Sometimes, it's not about the feature being used. It's about the user's confidence they won't get stuck (I can always back out this change! Oh! The backout button is gone?! Panic), or feel the product is supported adequately, or even, it's a checkbox on a purchase requirements list.

Remove features at your peril!

> web application that serves hundreds of thousands of requests every day

So in this case, that's at least hundreds of requests per day. I mean, it's not small.

I agree completely with this comment, and another comment saying that "which percent contains the value of the product", because that might be the most important 0.1%.

"A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies."

“Unfortunately, it’s never the same 20%. Everybody uses a different set of features."

For example, you've been handed a bug. The customer is important and is running a version of your code from three years ago. You have source control, so you check it out and try to build it. What stuff might you expect?

1/ It uses docker and the image isn't online any more. I've had this one.

2/ One library dependency you used to use has been deleted from the internet. Also had this.

3/ Another dependency is still available, but it uses a dependency which isn't. Not yet.

4/ You managed to gather all the code and it refuses to compile with a modern toolchain

5/ As above, but this time the modern toolchain makes a different program to last time

6/ Another dep has dubious ideas of semver and the current copy doesn't behave like the old

7/ Actually anything using semver is considered deeply suspicious in itself

That's off the top of my head. I think there's probably a long list of variants on the source tree isn't sufficient information to recreate old versions. The reliance on old compiler bugs feels particularly realistic to me, but then C++ people mostly check in our dependencies. I've definitely checked out npm projects from a few months earlier and discovered they don't run any more.

Compare to the silly, paranoid, I've-checked-in-gcc-and-linux alternative. You check out code from N revisions ago and it all builds and runs, exactly like it used to, provided you can find hardware which looks adequately the same as it used to. I've heard rumours of warehouses of new-in-box sun workstations waiting for their time to replace the current ones too.

On balance, I reckon the industry best practice of grabbing whatever code some server gives back with an associated version number is a nonsense and obsessively committing the entire dev and run state into source control is the right thing. But I'm clearly in a minority.