Most of the reasons why code is hard to understand will be on a fairly small scale. It is possible to yank that out and replace it, while honoring and respecting any underlying chaotic organization that may have occurred despite the crap quality of the code. (As the article says, this sort of chaotic adaptation requires flexibility and crap code only inhibits that.)
That's pretty much what I've done in this last calendar year, taken two messy systems chaotically (in this article's sense) interfaced with the rest of the company, and upgraded them. I gave them new, hopefully-non-crap code, certainly better documented code, documentation on the system structure, better operational deployment, massive upgrades to security, general speed improvements, and in one case, a fundamental architectural change at the most foundational level even though the surface that the users interacted with hardly appeared to change.
And yet... despite all that, I would not say I "rewrote them from scratch", because I did not simply start with a blank sheet of paper and start scribbling what I think the ideal solution would be. I took the underlying adaptations, respected them, assumed that they likely had a reason even if I didn't know what they were, and built systems that largely dropped into place on top of the old ones rather than being totally foreign bodies that cause cascading requirements for other systems to also be significantly rewritten.
If, in the future, those other systems do get rewritten, I even have some paths prepared (but not yet written) in the code for true architectural upgrades to occur in the future. But in the meantime, I have improved systems that work now.
It's a much better approach to replacing a system that denying the chaotic adaptations. Even "crap code" can be mined for them, and they are not generally the crappiness itself.
That's pretty much what I've done in this last calendar year, taken two messy systems chaotically (in this article's sense) interfaced with the rest of the company, and upgraded them. I gave them new, hopefully-non-crap code, certainly better documented code, documentation on the system structure, better operational deployment, massive upgrades to security, general speed improvements, and in one case, a fundamental architectural change at the most foundational level even though the surface that the users interacted with hardly appeared to change.
And yet... despite all that, I would not say I "rewrote them from scratch", because I did not simply start with a blank sheet of paper and start scribbling what I think the ideal solution would be. I took the underlying adaptations, respected them, assumed that they likely had a reason even if I didn't know what they were, and built systems that largely dropped into place on top of the old ones rather than being totally foreign bodies that cause cascading requirements for other systems to also be significantly rewritten.
If, in the future, those other systems do get rewritten, I even have some paths prepared (but not yet written) in the code for true architectural upgrades to occur in the future. But in the meantime, I have improved systems that work now.
It's a much better approach to replacing a system that denying the chaotic adaptations. Even "crap code" can be mined for them, and they are not generally the crappiness itself.