Why developers produce absolute garbage code

An awful lot of software is partly, or totally, composed of absolute garbage code. But why? Why, all together, we all agreed to produce garbage code ? I let you put on your mask, today we’re diving in the most disgusting codebases in the world.

Run Forrest !

I know you’ve already met a horror called deadline. The deadline is ugly, but at first it’s okay because it’s far away. At the beginning of our story, it’s all beautiful. You can hear Beethoven’s nine symphonies while you produce neat code. And suddenly, the deadline is for yesterday. Brutally, panic is the new normal.

You start commenting CI/CD jobs because “we don’t have time for tests”. A few days later, it’s getting worse. The situation is getting critical for the business side of things too. Now you’re sweating profusely and you’re starting to lose respect for any good practices. The QA doesn’t come to see you anymore, he’s also sweating at the other end of the open space.

And that’s it ! From now on everyone’s producing garbage code to finish this doomed project. The more time you spend in this situation, the more garbage you’re gonna get. And there lies the first explanation for a very large part of software with absolute garbage code. Maximally stressed devs who are often asked to do the impossible in terms of time. Obviously, they all turned crazy at the end of the project.

We often make fun of delays in the building sector. But in programming, I think we are world champions. As a company evolves and experiments with ways of doing things, this tends to disappear. Fortunately things are improving, agile ideas have made their way and fewer and fewer people are dealing with this kind of situation. That said, sometimes the garbage code is intentional.

Garbage code as a service

Producing absolute garbage code is sometimes what you need to do. Please keep calm, I have an explanation. It’s super important to be versatile as a programmer. Being able to write absolute garbage code very quickly can be crucial for the success of some projects.

A proof of concept, a demo, a prototype, you name it. Basically your boss wants you to come up with something really fast to prove that something is possible. With the crap you’ll give him, he’ll then be able to free up some time for you to do the project in proper condition. And it’s OK to do that. You also have to understand that people need proof of feasibility before investing maximum money in the sexy project you want to do.

Anyway, so you do it. You do it fast and it works ! The management is happy and you are preparing yourself to rewrite everything. But sometimes something unexpected will occur. Your boss will send you an email : “Congratulations ! I love what you’ve done ! Ship it now.”

The number of “proof of concept” I’ve seen in production is mind-boggling. I’m sure it’s one of the biggest reasons for crappy codebases. Prototypes with temporary code that goes straight into production are legion in the apps you use every day. Even a normal project has a time limit, so you’d think those types of projects wouldn’t survive long. Ho believe me, they live.

I often hear people say that “it’s just technical debt” and “we’ll catch up” eventually. Lies.

Technical debt : the perfect crime

I don’t know who came up first with this excuse, but it’s genius. Yes, technical debt management is a real valid practice. I’m talking about people who abuse the term. Because technical debt is supposed to be paid. It’s not just throwing three random buzzwords from an article you’ve read one day.

Practicing “let’s do it fast and fix it later” is the third big reason your app explodes in your hands when you use it. Because the “later” part never happens. And on this point the developers themselves are as guilty as the IT project managers.

I was talking about prototypes in production, but it’s not just that. The famous “management” of the technical debt is highly inflammable. And some men just want to watch the world burn. They’ll call it “voluntary debt”. When an unplanned new feature comes along, what happens? You’re gonna code it fast! Don’t worry, it’s voluntary debt, we’ll pay that in no time.

A few months later, when the time has come, nothing will be done. Priorities changed ! And you find yourself adding a feature in spaghetti code while hating your life. You’re wondering how you got there and whether the problem could have been handled beforehand.

Chaos design pattern

There is also another big reason for absolute garbage code. To understand it, let’s go back to the comparison with the building industry. Making the foundation of your app is very similar to making the foundation of a building.

If the foundations aren’t solid, your building’s gonna be shit. It’s going to collapse and if you’re in it, you’re not going to like it. Software programming is no different.

The quality of the design is critical for the future code of your application. Any problems at this point and developers will start making hacks to save the project. The more problems on the design part, the more absolute garbage code you’ll find. Before you know it, it’s all garbage code from top to bottom.

It’s also the developers’ fault?

In the grand scheme of things, most of absolute garbage code is the result of disastrous project management. Now that we’ve emphasized this, I’m forced to say that sometimes the problem also comes from the developers. There are unmotivated developers. People who are there to make money and who don’t give a fuck about the code.

They don’t give a fuck about you and your efforts to make a code base that’s safe. They don’t give a fuck about the product and its durability. And you can’t even imagine the interest they have in the company they’re in! Yes, an unmotivated dev with no investment contributes to your program crashing all the time. But that’s only a small part of the reason. A person like that often gets kicked out pretty quickly or leaves on his own. When these people leave, they are very often replaced by juniors.

Juniors who are propelled into a project like little monkeys in Elon Musk’s latest rocket. There are two major problems with this.

First, they get paid like shit and are expected to work like seniors.
Second, a junior developer can’t be at senior level because the project demands it.
Something that obvious is TOTALLY ignored by a lot of people.

You can’t recruit juniors and expect them to work like experienced seniors. It can’t possibly work.

The luxury of good code

Good code is not a natural gift given at birth. But good code can be learned. There are ways of doing things, ways of thinking, ways of dealing with problems. There are a billion things that – together – will allow you to make quality code. With quality processes such as test coverage, pipeline, code review and peer-programming, you get a little closer to quality.

But this is luxury. It’s expensive to do all this, it takes time. Time that most companies don’t have. A lot of software deals with absolute garbage code because quality is too expensive. Not all companies can afford to take the time. Not all companies can put resources into training or expensive developers. We can complain all we want about absolute garbage code. The truth is that it’s about time and money.

In the short term producing absolute garbage code is saving a lot of time and money. In the middle and long term, because you need to maintain and add features to your code, you’re gonna lose A LOT of money. And a lot of companies think only about the short term.

Epilogue

If everything you use breaks the second you click on it, it’s because people in panic mode worked on it. In a perfect world, project management is far-sighted and developers are as motivated as they are trained. But life is shit and at the end you’ll die. Meanwhile, if you find a company that really gives importance to quality outside of the buzzword: stay there. You’ve found a unicorn and they’re really rare.