This week, I was handed a project. It was something that was outsourced way before my time at the company. The company that wrote, and maintained it, have now closed / been sold on. As such, I was tasked with "get this online yesterday, as it's business critical". Upon opening the source code - I decided something. I don't like Italian food anymore. My reaction to the source code, and the project structure overall was this;

How does a project get into this state, what kind of ignoramus - yes, that's a word - would ever let it get this bad?!"

So, following my rage, and cheeky pint of liquid lunch to calm the nerves a little, I've devised a list of reasons why Spaghetti code is not only part of the developer's job - but a fundamental requirement at times.

---

<

p class="text-center text-gray-600 text-semibold italic">Note: I do not condone, nor encourage any of the following practises. These are simply observations I've made over the course of my career so far

---

Deadlines ⏳

This was an obvious one really. Nobody in Software Development has gone through their career without struggling with time restrictions.

A project, either new or existing, comes in - and you look at what you've got to build.

"3-4 weeks, 3 weeks to build, 1 to test", you whisper to yourself. Client, Project Manager, or other external requirements, of course, reply with "We need it live in 2 weeks. Make it happen".

You know, as all developers do, that 3-4 weeks is an overestimate. You always over estimate, so that you give yourself slack for issues, and the "refactoring stage" of the build. You can build it in two weeks, but really, you want 3-4.

Unfortunately, until Developers / Software Engineers, are given more control and involvement in project planning, and discussions - we're always going to get left lacking here.

You build the project in two weeks - and it works. Has it got true test coverage? No. Has it had proper a peer and code review? Most likely not. Is there a comment in there along the lines of;

# Don't remove this, it breaks everything, don't know why
# #TODO refactor
# Hacky, but works

I may not have guessed it exactly, but you know I'm close..!

"General Incompetence" / Ignorance 🤦‍♂️

Nobody, and I mean nobody, knows everything possible about your given language or software requirement. Even if they do, there is no way that they can know what is going to change in the future.

As such, there will be times that you put forward a solution that works for now, and the foreseeable future; that suddenly becomes a problem later on down the line.

This could be because you didn't know of a piece of functionality (I've seen SoftDeletion implemented in some custom way so many times now, I've lost count) existed, or you weren't comfortable using a package at the time.

It's not the nicest situation to be in. Knowing that something you've put time, and effort, into - is essentially going to be gutted, and is causing delays. But that's development for you.

Remember, Zend 1 was once a respected framework 😂😂

Incomplete/Insufficient Process 🔖

Finally, the main other reason that I've seen for Spaghetti/Ravioli/"really bad" code, is process.

We'd all love to work somewhere that has Peer-Programming, Code Review, Pull/Merge Requests, CI, TDD. But we don't, and we never will.

Companies, as it stands today, do not put enough priority on the above procedures. Due to this, things simply are not checked, and code "slips through".

In Summary 📃

Developers are human. We will write "crap code" from time to time. Sometimes this is due to us simply not considering one method over another, or not even knowing that they exist.

Give more time to developers for their projects. If possible, involve them as early as you can in the project talks - before it's even signed off or pushed into the workflow ideally.

Testing, and code-reviews are a thing. Companies need to start respecting them, and utilising them whenever possible. They enforce good practises, and can aid in the training of other less senior developers in your workforce.