Free spaghetti lunch
Everyone has seen spaghetti code and most programmers have written their fair share of it as well (though no one will openly admit that). Sloppy spaghetti code is bred from poor design and planning, poor coding practices, quick hacks, and band aides over bugs. What’s worse is that the nature of pasta code is such that when someone attempts to understand the mess they quickly become overwhelmed. As a result they want to hurry and get their mind out of the sloppy mess so they end up just doing more quick hacks and band aides so that they don’t have to rewrite the whole plate of spaghetti and make it make sense. Spaghetti is often filled with bugs which are nearly impossible to track down. As a result, band aides and quick hacks are applied instead of finding the root of the bugs and fixing them. It also makes writing any type of automated tests extremely difficult because the code isn’t structured in a very logical way. Writing tests along the way would help alleviate the spaghettiness because the structure would be more organized to facilitate the testing.
Now the question becomes what do you do when you have to work with spaghetti code? You add meat balls. You write more spaghetti when you have to. When you add new features, you can organize your code better to show how things should be done. Work on the spaghetti long enough and the whole code base will slowly start to unwind itself to you. Not because it was rewritten in a more readable and efficient way but more likely because you’ve gotten sloppy working with such sloppy code and you’ve learned how to make a mess yourself. The new code you produce can be beautiful but when you work in a messy environment you have little choice but to continue making a mess or rewrite the whole thing.