Introduction to causes of software spaghetti

When talking about software refactoring, it's worth stepping back and taking a moment to think about why we need to be worried about our current software processes.

Assuming you have been in programming for any length of time – either directly working on the code or more indirectly in some sort of project management – you will have learnt or developed a certain notion of how you would really like your software to be.

You will want it to be really well structured. Well designed. Well written. Modular. It will have proper separation of each of the different layers of the logic; business logic, application logic, presentation layer. It should be easy to change the software. It should be efficient. Easy to understand, well-documented. In brief, it should ideally be a masterpiece of modern software engineering, an exemplary demonstration of good software. It will demonstrate an internal structure and quality that simply has ‘professional’ written all over it.

And yet, if you have been in programming for a little bit longer, you will know that, somehow, almost for reasons you can’t quite put your finger on, software gradually goes off the rails. No matter how hard you seem to try, your software projects slowly but surely lose this dreamed of structure and clarity and become more and more the spaghetti code which you want to avoid.

Why does this happen? Is there any way to avoid it happening in the future?

These are vital questions.

Maybe you have always inherited existing projects, and they were already in a bad way when you took them on. At least there you can take no blame for the poor state that they are in now, and convince yourself that if only you’d been on the case, since the beginning, they would still be in that really good state which you would like.

Is this realistic, or would it have still gotten in the mess even with you at the helm from the beginning? And what about this software which seems to be already in a poor state, is there any hope for it, or is it really just a question of waiting impatiently for the day where it is rewritten or no longer needed? And even then, if it were ever rewritten, would it really be able to avoid the mistakes of the past? Or are there some negative factors in software development which just cannot be tamed?

You will guess perhaps that my answer to these questions is that there are a number of reasons why software almost always gets in a bad state. In this chapter I really want to take a look at those reasons. I want to examine why software tends almost inexorably to deteriorate. I want to have a look at the causes that push software in a negative direction, and why in many ways we should remain relatively pessimistic about being able to fully control these negative causes.

There are a whole range of causes which work against this dream of beautifully structured, well designed, flexible, well written code. Each one is perfectly natural, and generally unavoidable. Note, I said that these causes are largely unavoidable – there’s very little you can do about them. Indeed, in most software development, they are inevitable.

And each one has a detrimental effect on code quality, on code simplicity, on code flexibility. Each one pushes the code to become more and more disorganised. Each one pushes the code to become more and more complex. And each one pushes the code to be more and more difficult to maintain and enhance.

See my book The Refactoring Workout for more on refactoring.