Interesting article, but it seems to leave out some really important points: 1. Tests I really like Michael Feathers definition of legacy code being code with

Interesting article, but it seems to leave out some really important points: 1. Tests I really like Michael Feathers definition of legacy code being code without automated tests. I've worked with some pretty bad legacy code bases, but the ones with decent test coverage were mostly easier to change and to refactor in smallish steps. 2. Documentation Good documentation describing the reasons for the architectural decisions made (and, somewhat more importantly the reasons why other ways of solving the same problem were dismissed) could have prevented most of the bad choices made in that story. 3. Management Where was management in the story? They should have seen the red flags (high turnover on that project, ...), done at least exit interviews with people leaving, seen the risk of the tech debt in the code base and taken appropriate action.