| For personalities try Jason Friedman. Martin Fowler's Refactoring is a nice read too. But personally, I'd like to ask what business goal are we looking to solve? Because regardless of how murky a codebase can be, if that codebase keeps hitting a business goal, then we really can't drive a change in practices. So, we first present business goals. Here's a few examples: If the business goal is to give better estimates for fulfilling custom features faster, then testing would be the first in the list. Not even the release process. Tests lessens cognitive load for developers when they're asked "how long can we make this feature?". They'll have an idea that it'll probably break a bunch of services, etc. a.) If you're in leadership, ask for tests when people make a PR. b.) If you're not in leadership, look for the smallest part of the monolith. Write 1 integration test, add a CI integration, put it in a PR. Co-workers would probably like that. If the business goal is to give better SLA's (turn around time for addressing breaking bugs, scaling better), then the release process would come first. Regarding technical debt: One way to address technical debt is to slowly address it by folding in the effort of cleaning and refactoring inside a feature request. ex: making a new form about 2FA takes 3 days, but you can say 7 and explain that we'll setup a CI test build, then hit and address some debt regarding User Authentication along the way. It'll introduce as a "Clean As You Go" culture in the legacy engineering team, which will pay off in the long-run instead of having a huge amount of time just dedicated to addressing technical debt. The danger of separating "address technical debt" as a separate effort is it sometimes results into some unnecessary abstractions and over-refactoring: i.e. trying to make certain things too generic, bordering on building a framework. But then again, if the business goal was to make a framework for a business goal (maybe something the bizdev can sell), then it can definitely be made as a separate effort. Otherwise, it'll be seen in the bizdev as someone just "playing" around with tech. |