Why You Should Never Write Bad Code as a Software Engineer

A romp through the misadventures that can be caused by quickly built proof of concepts and hacks, in all areas of programming.

"We just need a quick hack as a proof of concept"

The Setup

As developers, we will have been in the position where we have been told "just build us a quick working prototype of x to woo the client". Or perhaps "we just need a quick proof of concept of Y so the boss can get the idea" - the budgets are always none existent, so is the brief, and the deadline was always yesterday. But you are assured it is just a proof of concept, so there is nothing to worry about if it's a bit janky.

Although these words give you some trepidation, you are eager to please the paymaster. So you start building away with all your might. It's only a proof of concept, so you throw in a few bleeding-edge libraries that you have been gagging to try out, and you cut a few corners here and there. The software doesn't quite have the test coverage you want, and you had to disable some security features you didn't really have the time to understand to get it working in a staging environment. There are also many ill-thought-out chunks of code written where time was the priority. But it's alright because it is just a proof of concept.

Except, proof of concepts tends to have a habit of becoming production code.

The Misadventure

It happens something like this. The paymaster loves the proof of concept and has a really pressing reason to get it into production ASAP. No need to rewrite from scratch, though, as clearly you have built it already? The paymasters are swept up in the facade of a working product, but they are unaware of the questionable things you had to do to make the "proof of concept". They are unaware of the string and bubble gum that's holding it all together.

The poorly tested, ill-thought-out code, complete with unstable dependencies and security issues, makes its way into production and becomes the technical debt of tomorrow. With a vague promise, "we can take some time to improve it soon", only then to find its way to the tail-end of the backlog, where it sits like a ticking time bomb, all the while the business becomes ever more reliant on it.

This is an act of software development theatre that runs so frequently that it's cliche. I have seen it lead to service outages, security breaches, data leaks and technical debt so deep that you will struggle to find staff willing to service it.

The Cure

Humans have an extraordinary ability to put short term gains in front of long term consequences. This is compounded by the fact that we live in a time where most stakeholders are none technical. Code is not a physical thing they can reach out and touch, so they take it for granted. They cannot distinguish a secure, well-made piece of software from one that will become technical debt. They cannot grasp how complex modern software development and maintenance can be. If they are presented with a working proof of concept, they assume it's good to go, and their financial objectives will weigh stronger on their mind than your warning that the software should never see the light of day.

For this reason, as developers, we must take responsibility for ensuring that we do not produce poor quality code or quick hacks to please our paymasters. Even if it is just for a "proof of concept" or as part of a hackathon where you are supplied with free pizza for giving up your weekend. We must never write code assuming that it will not be launched into production, because one day, it probably will.

First published here