Huge, ugly, broken legacy systems are a bear to work with and I've mostly spent time working on them when not at startups. The most successful project of my car

Huge, ugly, broken legacy systems are a bear to work with and I've mostly spent time working on them when not at startups. The most successful project of my career was a facade-and-rewrite in which I played a significant role and has billions of $ of annual revenue behind it now, so I think I understand this issue fairly well. I also played a significant role in another similar project that, after I left, spiraled completely out of control and became a disaster that, 8 years later, is still not finished. The "this is dumb, we should rewrite it" reaction people tend to have when exposed to very large, complex legacy software systems is totally understandable, but really comes from a fundamental misunderstanding of the forces that drive software development at organizations which have legacy code bases. Yes, the re-write, if it gets "done", is basically guaranteed to be "simpler and cleaner" when it arrives; of course it is! It is being compared to a code base that's 20 years old, not just from an era where the technological compromises were completely different, but also from essentially a different world of what was acceptable at the time. In addition to that, all software that lives long enough tends to become a mess. Let's see how the rewrite is in 20 years. Oh, but wait, this time will be different. This time we won't make quick fixes and little hacks, we'll be diligent about requirements, we'll refactor and clean up when change is needed ... Everyone who has not should read "The Big Ball of Mud" ( http://www.laputan.org/mud/ http://www.laputan.org/mud/ ) which is about the clearest description I have seen of the reality of legacy systems.