> "so you have service that does X. it do it very well. you can put two people to support it and have rest of people focus on next innovation. instead, you take team of 9 people including 2-3 managers and engineers do some marginal improvement.

you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work."

I think you are mixing up three things:

- 1. A feature being done "X works very well".
- 2. Scope of software "When is Product Y that does X finished?"
- 3. Politics/Software mistakes "Does this software suck because it was written by monkeys or because our pointy haired boss gave us some expensive crapware"

1. Is a matter of philosophy. Unix one is that a tool does one job, does it well, then it is finished. I think this is the real "being done", the OP's post is so much nonsense. It works, it keeps working, in absence of a better tool, it doesn't make sense to re-invent the wheel. Even if you do (invent flight, e.g.), not all use cases make sense for flight (delivering goods by rail is much more efficient and less error prone than any drone fleet could ever hope for, at least over distance).

You do lose some convenience, if you want a hole borer you could either use a screwdriver (or similar) and a hammer, or you could buy or build some fancy pneumatic tool, but really, how many hole borers do you want to buy (concrete vs wood vs acrylic)? The urge to put everything into one product is the mistake - it saves some time up front, but it really only makes sense when you have the persistent and constant need at scale - in my example, maybe if you are building houses, but not for someone who just wanted to do a repair or make some wood furniture.

2. The scope of the software, is defined in part by its philosophy, but in the end it ends up having one, and generally being better at a couple things versus terrible at a bunch of things is the difference between a successful product and dead product. Think of Windows, or Mac OS - the former is good at video games (for a variety of reasons), otherwise besides momentum it doesn't have much going for it. The latter too - its good at video/photos and great at creating iOS apps. Otherwise it too doesn't have a whole lot going for it. Not to leave out the third, Linux, its good at configurability, and great at being a server/embedded OS, otherwise there's a whole lot of reasons its not so great.

What is the scope of the scope? Well that's called having a feature set, being able to release. If you engineered well, there is little long term support. Or if there are technology changes/upgrades, then support is required as well. This affects large and small apps, regardless of philosophy - OFC large apps seem to change frequently, but even small ones get security upgrades, bug-fixes, even occasionally new features if the use is common enough.

3. Deciding what goes where and who does what, that's politics, not software. Even the act of a team of engineers working on a project, is cause for politics. But that's still just what some humans did, and it doesn't necessarily reflect reality. Sure, some product probably gets bloated some busy work happens, but if you can still use the (old) software, that doesn't matter. At least until it stops become possible to safely use, the software is fine.

Besides, for open source projects at least, when this time (inevitably) comes, the point of the license is to allow for forking, restarting with something that still works or recently did work.

I think the only time I can justify this sort of "just throw it away" behavior, is for when you have a closed source, decades old piece of software which cannot be modified. Even with proprietary software, you can re-use source or binary components. Even for non-modular monolithic code-bases, you can extract business logic, utilities, etc, pretty much the only time this is not possible is in case of direct or indirect obfuscation, and even then it is usually not of possibility but of practical cost.

When you attempt to re-build the project from scratch, you may attempt to start from simpler principles, usually to either run into the same bugs, (re) discover your set of principles is incomplete, or simply find yourself rebuilding the same solution, maybe with a face lift, or running on the latest and greatest platform.