This reads like a blog written by someone who sells expensive consulting for business critical issues, but not to actually solve them, but dispense Eastern Wisdom to the poor developers facing and impossible and unsavory task. This sounds like this was written by a guy who was never directly responsible for producing actually usable and productive results.

This is done so management can lay back and say they already did their due diligence, now you know how to do it, now off to the mines! And be ready by the end of next week!

First:

If your codebase doesn't come with tests you are fucked. There's no possible way you can refactor anything without angry customers calling next day you broke their use case. I worked on legacy code that did come with tests (or even better, well written docs!) And even then it was basically everyday that we broke some elaborate use case checked by the tests.

Management will never approve of a refactor, and with good reason.

> unit tests are fast and reliable

They are also often worthless, because they don't capture real world behavior. Not always but having to mock out half your codebase (including libraries you couldn't possibly know how they work, like a legacy version of Qt your app depends on). You end up with five hundred lines of mock for ten lines of test and it doesn't even give you confidence in anything. These workshy consulting ghouls often force devs to write unit tests, who full well know they're going to be absolutely worthless.

Because you have no idea how it's supposed to work.

> Don’t make your code depend on libraries’ implementation

Good advice , though isn't the definition of legacy code that its already written and after refactor it should keep working like it already did? If somebody before you pulled in a COM object from Microsoft Excel 2003, and your ERP system pivotal to your companies success relies on the exact behavior of that component, where does that leave you?