[charlie0]

It's not that it wouldn't be applied to the whole codebase, it's that it wouldn't be applied to the whole codebase __at once__. You have to start somewhere and new features are a good place to start new patterns. Older code can be refactored piece by piece.

[strken]

In the majority of places I've worked, nobody who started refactoring older code piece by piece ever finished it. The exception is people who documented the scope of the work, got leadership buy-in, and then worked on it continuously like any other project.

The problem is that sometimes the new pattern gets overridden by an even newer pattern, and so on, until you've got three different implementations from 2016, 2019, 2021, and then you find that in 2024 you're working on implementation number four and all the people who did the first three have left the company without writing any documentation or finishing their work.

[stickfigure]

In a sufficiently large codebase, this is just simply inevitable and you just have to accept it as a fact of life. If you have millions of lines of hand-written code, you're going to have archeological layers and some pockets that are more modern than others. It's not great but "everything is locked into a pattern established in 2003 and you can't innovate" is a worse problem.

[8n4vidtmkvmk]

This is why I always ask "Is this going to leave our code in a better or worse position if we abandon yhis half way through". If the answer is "worse" then don't start it. Not unless you can get the entire thing done in about a week. If it takes a quarter, the probability of reprioritization is way too high.

[sidmitra]

I've had success with strategies at introducing some abstractions/patterns at my current place(doing this alone for a enterprise SaaS company with 200-ish devs). It's weird that we don't teach these or talk about them in software engineering(AFAIK). I see them being re-invented all the time.

To borrow from medicine: First step is to always stop the `stop the hemorrhage`, then clean the wound, and then protect the wound(or wounds).

- Add a deprecation marker. In python this can be a decorator, context-manager, or even a magic comment string. This i ideally try to do while first introducing the pattern. It makes searching easier next time.

- Create a linter, with an escape hatch. If you can static analyse, type hint your way; great! In python i will create AST, semgrep or custom ones to catch these but provide a magic string similar to `type: noqa` to ignore existing code. Then there's a way to track and solve offending place. You can make a metric out of it.

- Everything in the system as to have a owner(person, squad, team or dept). Endpoints have owners, async tasks have owners, kafka consumers might have owners, test cases might have owners. So if anything fails you can somehow make these visible into their corresponding SLO dashboards.

  The other alternative to this last step is "if possible" some platform squad can take over and do this as zero-cost refactor for the other product squad. Ofcourse the product squads have to help test/approve etc. It's an easier way to get people to adopt a pattern if you do it for them. But the ROI on the pattern has to be there, and the platform squad does get stuck doing cruft thankless work sometimes. If you do this judiciously the win might be thanks enough, like more robust systems, better observability/traces, less flaky tests etc. etc.

[8n4vidtmkvmk]

> test cases might have owners

I hope the owner is the same person that owns the code.

[sidmitra]

Easier said than done :-)

Tests might cover more code than a single unit owned by different teams, thus end up with multiple owners. Prefer "squads" as the owners rather the individuals.

But just like documentation the ownership might be stale and out of sync. So the idea would be let some reds in SLO dashboard correct them over time. It's not possible to automatically link "tests" to the "code" always.

[8n4vidtmkvmk]

End-to-end tests might get tricky. But unit tests should be owned by the person/team/squad that owns the unit.

And unit tests should never break/be red. If the code needs to changed, the test needs to be changed at the same time.

End-to-end tests can be flaky. Those probably shouldn't prevent deployments and can be red for awhile. Should probably manually confirm if the test is acting up, there's a change in behavior, or if something is legitimately broken before ignoring them though.