Mistakes engineers make in large established codebases

I once did some contract work for a development group at Apple in the late 90's working on a product not yet released. It was the first time I was exposed to a large codebase that could be updated by any of a large number of programmers at any time. While investigating a bug, it was scary to constantly see large, complicated routines headed with comments from 20 or 30 people logging the changes they had made. There would be no consistent style of code, no consistent quality, no consistent formatting, no real sense of ownership, a real free-for-all. The system not only immediately projected a sense of hopelessness, but also indicated that any attempts at improvement would quickly be clobbered by future sloppy changes.

> you cannot split up a large established codebase without first understanding it

I’ve seen enough wild rewrites to realise they often create more chaos than they solve. Over time, I’ve come to view older codebases as living libraries of knowledge, rather than something to refactor out of existence. Every quirk usually has a backstory or a user need behind it. It’s less about ripping everything apart and more about respecting those conventions so you can make use of them.