Is there a way to avoid spaghetti code over the years? [closed]

Question

I've had several programming jobs. Each one with 20-50 developers, project going on for 3-5 years.

Every time it's the same. Some programmers are bright, some are average. Everyone has their CS degree, everyone read design patterns. Intentions are good, people are trying hard to write good code but still after a couple of years the code turns into spaghetti. Changes in module A suddenly break module B. There are always these parts of code that no one can understand except for the person who wrote it. Changing infrastructure is impossible and backwards compatibility issues prevent good features to get in. Half of the time you just want to rewrite everything from scratch.

And people more experienced than me treat this as normal. Is it? Does it have to be? What can I do to avoid this or should I accept it as a fact of life?

Edit: Guys, I am impressed with the amount and quality of responses here. This site and its community rock!

Answer 1

Ruthless diligence combined with constant unit testing is the only way to prevent spaghetti code. Even then it's only a band-aid solution. As soon as you stop paying attention out comes the pasta.

Very often I find that spaghetti code is introduced because someone is just plain being lazy that day. They know there is a better way to do it and just don't have the time. When you see that happen there is only one thing to do.

Call them out on it and ask them to change it

I find that pointing out the better way during a code review is usually enough to get people going. If they check it in and I feel strongly, I'll refactor it myself.

Do I occasionally come off as a little bit eccentric? I'm sure I do. Frankly though I don't mind. I'm not a jerk about it and approach this in the best possible social manner. However letting bad code get checked in pretty much assures that I am going to have to debug it at some point in the future. I'd rather take a little flak now and get the right code in.

I also feel that a culture of unit testing also helps prevent spaghetti code. It's much harder to unit test spaghetti code that well factored code. Over time this forces people to keep their code somewhat factored.

Answer 2

I believe the key to avoiding code rot lies in sound bottom up design and implementation methodologies (I believe it so strongly that I named my business - Think Bottom Up - after it!). The tools of choice here are:

• Programming by contract
• Layered design
• Focus on decoupling
• Always build with reuse in mind, looking for generic solutions
• Keep frameworks lightweight, simple and focused

As suggested by other respondents, you need to catch problems early. With green developers, this means mentoring (pair programming is great here) and reviews (code and design reviews). With more senior developers, this means vigilance.

Most of all, do not be afraid of refactoring. If refactoring scares you, you're already sunk. If refactoring is seen as "bad", then there is something wrong with your business.

When you fix something, fix it properly. I use the term "fux" to describe a fix that was done the wrong way: it just "fux" your code base.

Cheers,

Dan