> So instead, put effort into making it easy to remove.

You might, but there's also going to be other people that will happily go ahead and create abstractions and logic that will form the very core of a project and entrench themselves to such a degree that they're impossible to get rid of.

For example, you might stumble upon CommonExcelFileParser, CommonExcelFileParserUtilities, HasExcelParseStatus, ProductImportExcelParser, ProductImportExcelParserView, ProductImportExcelParserResultHandler and who knows what else, the kind of stuff that ends up being foundational for the code around it, much like how if you start a front end project in React or Angular, migrating to anything else would be a Sisyphean task.

In practice, that means that people end up building a whole platform and you basically have to stick with it, even though some of the choices made might cause bunches of problems in the future and, due to all of the coupling, refactoring is way harder than it would be in an under-abstracted codebase.

I'm not sure what to do then. People seem to like doing that more than applying KISS and YAGNI and making code easy to delete.

Not my originals, and I cannot recall who said this... But it's completely on point

* Software has a tendency to become maximally complex. You either have an actually complex domain, or the developers will find a way to increase the complexity (..because otherwise, they're bored)

* Good software is modular and easy to remove. Consequently, good software will keep getting replaced until it's bad and cannot be removed anymore

Hard to remove doesn't mean impossible to remove.

Refactoring or fixing bad codebases is a thing.

Yeah, it was probably "won't be removed anymore" or similar. As I said, I don't remember who said it and was kinda paraphrasing

Dealing with precisely this right now. Written by a consultant who I, maybe uncharitably, suspect is trying to ensure his job security. At this point, it is harder to even understand what's going on behind layers of handlers, factories and handler factories, forget about removing things. It works though and so no one wants to stick their neck out and call it out for the fear of being labelled "not smart".

It still depends. Business line application yes and 10x yes. It will change it will move, don’t try to foresee business requirements. Just write something that will be easy to replace or throw away.

Frameworks and libraries not really, for those you still have to adjust to whatever happens in the world but at much saner pace.

Biggest issue is when devs want to write “framework” when they work on business line application where they have frameworks that they are already using like Rails/Asp.Net etc.

I would say the biggest issue are the frameworks themselves: they practically force you to fit your code to their architecture, and before you know it, your logic is split across innumerable classes. Laravel (with which I have the most experience) has models, controllers, views, service providers, data transfer objects etc. etc. - that makes it (arguably) easier to write and extend code, but very hard to refactor/delete.

> Business line application yes and 10x yes. It will change it will move, don’t try to foresee business requirements. Just write something that will be easy to replace or throw away.

This is correct, but from my experience of working in the same company for over a decade: You'll learn to foresee requirements. Especially the "we'll never need that" ones that become business critical after a few months/years...

Like the path that starts with a "simple" system of "soft deletes" for Foo records, which progresses through a period of developer-assisted "restores" or merges, and then they want even older info, and to make reports...

However it would have all been so much easier if they'd realized their business domain called for "Foo Revisions" in the first place.

Sometimes things change, sometimes we chose the wrong abstraction.

Unless you’re writing the Linux kernel you shouldn’t write it like the Linux kernel.