If you fire those people, you remove your source of expertise on the old system. Yes, they did a poor job of maintaining the old system, but their knowledge may be valuable to understanding the old system and creating requirements for the new system to reach parity.

" I would start by firing people that led to this situation."

You are one of those blessed people who can architect a system and the architecture holds up for decades. From my experience most systems will end up in a big mess over time if features get added. There is almost no way around it.

> You are one of those blessed people who can architect a system and the architecture holds up for decades.

This is exactly why maintenance is needed. Proper maintenance that includes things like updating the architecture and gradually migrating the whole system to that architecture, rebuilding small unwieldy components, updating and migrating database schemas as the product evolves, removing unused features.

If a product is just getting bugs patched and nothing else then it isn't really being maintained, it's being deprecated. Unfortunately as an industry we still think that there are distinct build and maintenance phases and that the latter can be done with less resources.

Yup. So much of the time the system starts out at one thing and morphs to another. That can easily lead to core problems with your architecture

> I would start by firing people that led to this situation

Thereby fomenting Red Flag #4, not "working with people who were experts in the old system.”

I am not saying to fire everyone. I am just saying that someone needs to be responsible. If you keep the same people in power they will repeat the same mistake. You need to keep domain knowledge but clueless management is just a burden.

That's utopian. The reason cautionary rules like those in TFA exist is because "just undo/revoke all the bad shit that led to your current situation", while certainly appealing in concept, is often impossible in practice. Instead, litmus tests like these, which can be practiced at the dev team level, prove useful. Who knows, if enough dev teams at a company arrive at the same conclusions using reasoning like this, perhaps they really can put enough pressure on management to induce firings of prominent debt-incurring people. Even (and more likely) if not, that understanding at the engineering level will help mitigate future damage/mistakes.

New people will repeat most of original people mistakes too - many bad designs look good before you tried them.

But also, wtf is it with people that the first instinct in any kind of situation is to fire everyone.

I think it's the phrase used by someone else in the comment chain: "clueless management".

You can have the best developers and architects in the world, but clueless management will sabotage anything they do, whereas good management can accomplish plenty with teams that aren't the best possible.

They're already gone, almost certainly.

I've found that they are usually still there but as they are the CEO/CTO it's difficult to get them fired

Hey, a bunch of shell scripts glued to some DOS executables were good enough in my time. We had no fancy schmancy github back in those days, yet we built this business on nothing but hard work and pizza.

Why, the sources of the DOS exes were long gone by second year, lost in the crash of that old Windows Milenium machine that used to sit in our dorm room and was uniquely configured to compile them using Turbo Pascal - we figured it was a safe option to use as a source repository. But that still didn't stop us - we implemented the remaining features by patching assembly.

That, or you are their replacement.

People write legacy systems from day 0, especially in resume driven development.

Often those people are high up enough that they are not going anywhere.

For example an executive/management team that over-commits the organisation and creates a culture of rewarding technical debt and punishing maintainers.

Rather than fixing these issues they will continually search for a super hero employee who is going to come in on a white horse on monday and fix it all up in two weeks.