I’m sure all software developers will be well aware of the dangers of spaghetti code. That nightmarish code that is rigid and inflexible by nature, and difficult to comprehend and maintain. Changes to spaghetti code are hard to implement and are fraught with unexpected side effects which often result in making the code worse instead of better.
But how does spaghetti code get created?
Spaghetti code just doesn’t arise spontaneously though. Very rarely does a single software developer sit down and write a whole bunch of spaghetti code. More often than not, spaghetti code started out as the new kid on the block, all shiny and new. Well designed, well implemented and totally rocked. However, just before shipping, a bug was found, and it needed fixing pretty damn quickly (PDQ). So a hastily implemented fix was put in place, and everything was sorted.
Due to project delays and time pressures on the next release, no one had the time to go back and refactor the code, so the hasty fix remained. After releasing the software, a very vocal customer shouted very loudly that they needed a feature for them to use the software. They shouted again, and the software manager agreed to give them what they wanted. So another hastily implemented feature was put in place. A few more vocal customers also shouted very loudly and they too also got their features.
Just before shipping, a few urgent fixes were found in the unscheduled features that were implemented to appease the shouty customers. These had to be fixed PDQ.
And so on and so on. Vocal customers demanding unscheduled features. Bugs found late in the process before shipping And never the time to revisit the code to make it all shiny and new again. It doesn’t take long before that shiny new code that totally rocked, has gradually degenerated into a sloppy heap of spaghetti code.
There is no simple solution to this problem, and an entire book could be devoted to the subject, but it’s usually a combination of one or more of the following that leads to spaghetti code.
- Inexperienced software developers
- Poor project management
- The business failing to acknowledge the problem and address the ever growing problem of technical debt (an issue I have discussed previously here What is Technical Debt?[^]
The first two problems can be rectified without too much difficulty by training and education. The latter is more problematic however. Getting the business (any business) to spend time going back over the code and refactoring it when they have already agreed new functionality and deadlines with the customer is nigh on impossible. It is easier knitting spaghetti than to persuade the IT Director of the importance of technical debt. Yet the concept is stunningly simple.