http://www.perlmonks.org?node_id=499648


in reply to Spaghetti code...

about spaghetti code is how much more spaghetti it begets. In the initial stages, this is known as alpha begetti spaghetti (sorry!).

Once you find yourself mired in Spagcode, any changes quickly take on the mode of "Crap! this is too much work to do properly by deadline! I'll just put this hacky bit of cruft in here to make it work now, and come back to do it properly later".

Of course, those who have been in software development long enough to have worked on OPS (Other People's Spaghetti) also know that "later" never comes.. so the hack you quickly threw in to meet the deadline becomes yet more spaghetti for someone else to deal with. Often, that someone else is an older you.

Eventually you reach a point where it is simpler to declare the spaghetti 'obsolete', and begin work on version 2.

Yes, this is the bitter voice of experience :)

Replies are listed 'Best First'.
Re: The worst thing...
by Aristotle (Chancellor) on Oct 13, 2005 at 09:03 UTC

    It depends.

    Hateful as spaghetti code may be, there’s also the plain fact that it has worked in production for a while and has accumulated various bug fixes too. If you start over from scratch, you have to redo everything, including the parts which happen to be decent (which is the majority of the code even in most “bad” codebases), and you will likely run into half of the same bugs all over.

    You are almost always better off refactoring the spaghetti code iteratively as you work on it. Instead of adding just one more hack to make something work and deferring the proper implementation for later, clean up that one corner of the code you’re directly working on, as far as is sanely possible, and add your change on top of that. The right way to do this, of course, is by writing tests for the part of the code you are about to clean up, so you can be confident that your cleanup doesn’t break anything. Over time, the codebase will slowly tend towards sanity, and as you go along you will progressively accumulate a test suite that will give you confidence to attack the code more aggressively in the more seriously broken parts.

    Most of this work is quite mechanical.

    Very few codebases are so hairy and disastrous that throwing away the good and known working parts they contain is justified.

    Makeshifts last the longest.