a legacy codebase can be structurally resistant to being fixed.

you're afraid to change things because there's no test coverage. okay let's add some automated tests. oops can't do that either because the whole thing is a tightly-coupled pile of spaghetti with no interface boundaries. so you start by refactoring. but because there are no tests, you don't realize you are breaking a bunch of important business functionality and now people are yelling at you to stop whatever you are doing and fix these bugs.

no matter what you do, it's going to get a lot worse before it gets better. but hey, people are actually getting stuff done with your product/service in the meantime. as painful as it is, it's still probably better to fix what you have than to start over.

This captures the backwards compatibility and long range entangled dependencies aspect of change resistance. It misses the aspect of organizations that is agent like, capable of homeostasis. Unlike static code, when things change, such systems will actively seek policies and apply levers of control to maintain the present equilibrium.

Like biological agents, I'd argue any persistent and stable organization of humans makes predictions and inferences about the future and takes actions which maximize the probability of their future existence as a coherent entity.

in a vacuum yes, the legacy system doesn't have any of those agent-driven issues. given enough time and freedom from interference, you can incrementally fix it or rewrite the whole thing from scratch. but if you leave out the context of users and management, it doesn't really matter how you choose to fix it or whether you do at all.

in reality, you have customers that are very upset about the sudden spike in observable defects, you have other teams mad because they are triaging a bunch of bugs introduced by your refactor, and you have management wondering why the fuck you have spent multiple months working on stuff that has no clear connection to a marketable feature. you might also have a couple of seniors/principals who actively oppose your efforts because they benefit from being the only people who really understand the mess you are trying to clean up. and of course, all of that messy people stuff is probably a large part of why the system is so tangled up to begin with.

I certainly don't think political systems are exactly like computer systems, but it seems like a lot of the high-level lessons are applicable to both.

> in reality, you have customers that are very upset about the sudden spike in observable defects...a bunch of bugs introduced by your refactor

That's what I meant to capture by agreeing there is overlap in terms of backwards compatibility and entangled dependencies.

The difference is entrenched social systems have greater agency that goes beyond change induced instability and into being able to actively predict and favorably mold their environment.

Software development is not always the best metaphor for everything.

> Fixing your old legacy software takes time, but probably less time than starting over from scratch.

Is it though? The current system is the equivalent of some old unmaintainable shit written in COBOL by a guy who quit after 30 years while making the codebase as terrible as possible to maintain job security.

>Is it though? The current system is the equivalent of some old unmaintainable shit written in COBOL by a guy who quit after 30 years while making the codebase as terrible as possible to maintain job security.

Almost always. Re-implementing all the existing functionality from scratch will take much longer than you think or estimate. And attempting to remove/defer implementation of any will cause friction with business that rely on it.

There is a reason why we haven't replaced Excel/Word with google sheets/docs. It's true that most people only use about 60% of any software but everyone relies on a different set of 60%.

> The current system is the equivalent of some old unmaintainable shit written in COBOL . . .

It just isn't! It really isn't. It is the way it is for good and historically motivated reasons. Can you elucidate those things? If you don't understand the rationale for the system as it exists, you can't propose an alternative that has any chance of success.

>The difference here is that the existing codebase isn't just broken, it's structurally resistant to being fixed.

The key point here then is that the engineers and maintainers of that original (legacy) system probably did not properly take scalability and structure into consideration. Maybe the system was pre-SDLC, which is an important consideration, but each system is usually a different case, and some tech is often labeled as "legacy" because it's simply not part of a "bright and shiny new money-making solution" marketing plan... ehem.

It's important to not create the same issues in redevelopment, and reducing complexity is a key step in ensuring future compatibility.

Some systems are not as "legacy" as others. This is also a vital point to the discussion.

Most clients aren't concerned with overall cost and lifetime of service on solutions from what I've observed; Most clients are people working towards raises and their retirement and just concerned about not exceeding their max budget and not generating embarrassment for themselves or for their company.

This is why one of the first questions I ask of my customers is how long they intend for the system to be in service for.

There are several factors of why a proper solutions architect is necessary throughout the development process of major and mission-critical systems, but too many PMs decide to just use the tech stack a team agrees upon, or what's cobbled together and patched to work, or what worked as an MVP during early demos.

We suffer from environmental factors, because budgets are under-cut, deadlines are always too short, and because people only care enough to prevent their own headaches. This does not meet a mark for vital systems though. As we ignorantly rush towards more and more software dependent operations, the failures will become more and more amplified in all aspects (cost, loss, recoverability, technical debt... you name it).

Keeping everything as simple as possible is now, and always has been, the better ideal.

Any process inscribed in the technology is part of a larger business process, and as such is also resistant to such change. You can do refactoring all you want, which by definition means not changing inputs and outputs. But you can't change the process without looping in business. And then it becomes about making a business case for spending the money and time and training and etc to make a change to the business process.

The "legacy financial system" exists in the way it does for specific reasons. Do you understand those reasons? It's a Chesterfields Fence situation: unless you can elucidate those things, you're not qualified to propose an alternative.