Business requirements or engineering dependencies can change quickly in some scenarios, meaning code gets replaced regardless of its quality. I've had to delete a lot of code the past few years, much of it 1 year old and very carefully written. Someone wasted his time.

Obviously I don't know the specifics of your situation, but "very carefully written" doesn't necessarily equate to "good". Part of what makes good code good is its flexibility in the face of change. Barring an early-startup-style total pivot to a completely different industry, business requirements shouldn't just completely change like that, unless they were incompletely fleshed out. I could see some kind of API-adapter code having to be completely thrown out if you move away from that API or dependency; indeed you're right that that doesn't need to be great code since there's no expectation of deeper reusability there.

I do think a lot of code is written prematurely, which may be what happened there. If code is premature, it's not worth spending the time to make it good; but most likely, it's not worth writing at all. A large majority of the total time on a task is spent fully understanding the problem being solved, with much of the remainder spent coming up with a high-level approach to the solution. Actual meaty code-writing is a pretty low percentage, so even doubling the time spent here shouldn't increase your overall time that much. Since writing the code is the crystallization of all that prior effort, you can liken writing good code to "taking good notes". It indeed seems silly to say "man, someone wasted a lot of time taking really good notes about that lesson they were in." If it was not worth spending time to take great notes on the lesson , then the lesson itself was not worth it.

It was good code. Some was using a database that got deprecated within our department. Some had business requirements that change pretty frequently because despite being a large company, we have some moving targets in what we deal with.

> there was this little framework someone wrote where logic was encoded in config files.

This is one of the most common and traditional shining exemplars of awful code. Absolutely nightmarish stuff. Such code can only be written by someone who has absolutely no idea what programming even is. They looked at a problem and said: "You know what this problem needs? It needs a much worse programming language that I just invented, jammed into a config file." So the code was tremendously awful to begin with, and you threw it out. Good for you.

> I said look, we're SWEs, we know how to edit code.

Absolutely right: this is why we use programming languages to program, and not config files. Again illustrating that you never threw away good code; you threw away the trash.

> I'm replacing this with something centered around an if-else tree that just does exactly what we need right now and can be modified later, with little attention paid to quality. I'm not even gonna bother splitting the codebase into multiple files cause someone is probably gonna have a strong opinion about organization; that person can have fun doing that. So far that's been modified a lot in the past 3 years with ease, it's gotten the job done, and anything more structured would've broken during that time.

A chain of if-elses is probably not paragon-level code, but definitely an improvement over what you described as coming before. My overall impression is that nobody has really taken the time to sit down and really dig deep into the problem, extract out the invariants, model things mathematically, identify the important operations you need to perform, develop useful data structures to support those operations, etc. My feeling is that if it was actually set up well -- really well -- you'd look back on your current situation and cringe.

It's statements like "anything more structured would've broken during that time" that make me think you really just haven't been fortunate enough to even experience what good code actually looks like. You can't imagine the situation being better. But it can.

Does it need to be? Maybe not. Either way, this is still a story of replacing awful code with better code.

First off, I deleted the part you're replying to cause I didn't think anyone would bother reading it, but you quoted it during that time, so I apologize for the ninja edit.

The code I deleted was sensible for the business requirements at the time, and the author thought it through. It wasn't a whole DSL (which I agree is a classic mistake), was just a list of regexes and a few other variables. We had to support new pieces of inventory in our system, and adding onto the list/config was easier than rewriting code. You might fault the author for not predicting that assumptions would change and building something more flexible, but I don't think it was doable. I think the author's real mistake was spending so much time on something impossible to predict.

If I'd put more thought into structuring my new code (as I normally do for other projects), it would've been thrown away regardless, because more things they told me were "invariable" changed after I did it. And if I assumed everything was variable, it'd take way too long to write the system, so the tradeoffs pointed to writing bad code and not caring. I had several other projects on my plate that were worth spending the time on.

We had the opposite problem with another system a teammate wrote for maximal flexibility. It was composed of several carefully abstracted layers. This made the system just too complicated to deal with, as nothing even used that flexibility, and some new features even started breaking his abstractions. When he left the team, I rewrote it to only do what we need today with 1/10 the LoC, and it's way more stable. My new cross-system design has that whole thing slated for removal too. That code will live only a year.