Guess who needed the columns to build a feature a year later? …

Thanks for this balanced (and IMO necessary) reminder. It's all too easy to get caught either doing way too much defensive/speculative stuff, or way too little. one person's "premature optimisation" is another person's "I've seen roughly this pattern before, I'll add this thing I wished I had last time" - and AFAICT there's no _reliably_ helpful way of distinguishing which is correct.

What was the DB migration required for those particular columns? I presume this was not the only time such a migration needed to be done to add columns. Is it possible that as new features emerge, new columns and migrations will need to be done anyway and one more or less migration would make less of a difference on the grander scale?

In most cases though, anticipating requirements results in building things you don't need. And if you do need them, you usually end up needing a very different form of it. The worst codebase I have worked on is the one that was designed with some complex future-use in mind. In your example as well, the codebase only required columns a year later. So I think removing all chunks of code that anticipate a future need sets the right precedent, even if you end up needing it eventually.

> But the original work had taken me maybe an hour. And the cost of keeping the data around was approximately zero. It seemed he didn’t consider that. i guess this is very illuminating - you have to predict the cost of adding YAGNI, before doing it. A low cost YAGNI feature might actually serendipidously become useful. I feel this is the same principle as random side projects, not done out of necessity but out of curiosity and/or exploration.

I think when you have a mindset of removing the useless (which your columns were at at the time) you have to be prepared to sometimes add things back in. Yes, it is painful, but it is not a signal that the process didn't work. You should expect to sometimes have to add things back in. We cannot perfectly predict the future, so when removing things there will always be false positives. The only way to get a false positive rate of zero is to never remove anything at all. The real question is what level of false positives we find acceptable. If you can only cite this one case where it was painful, then I'd say that's evidence your colleagues approach worked very well! (I think Elon Musk recommends a deletion false positive rate of 10 % as appropriate in general, but it will vary with industry.)

The big difference here is something the user sees versus the developers as in your example. For users I think the answer is almost always, less is better. For the developers also, but there’s a bit more leeway.

Main issue with adding something you might need in the future is that people leave, people forget, and then, one year later, there's some metadata column but no one remembers whether it was already used for something. Can we use it? Should we delete it? Someone remembers Knight Capital and spectacular failure when old field was reused. So it's always safer to keep existing field and then you end up with metadata and metadata_1. Next year no one remembers why there are two metadata fields and is very confused on which one should be used.

In this case you where right, and the removal of the additional fields turned out to be a mistake. More often though I see this going the other way, you end up carrying around tables and fields that aren't needed and just muddles the picture. Even worse is "Well we added this field, but we're not using it, so let just stuff something else in there". It can get really ugly really fast. The article is a little different, because "YES, they do need the calculator, people should know what your service costs up front". If they want to do away with the calculator, then they should restructure their pricing plans, so that it will no longer be required. That just not an IT problem.