Software projects are incredibly hard to maintain. In many cases when developers get handed an old project they prefer to re-write it than to understand it.

This is an incredibly costly problem and hard to counter. Not impossible though. As I like to say: all you need to write good, scalable code is to have good taste.

The more complex a codebase is the harder and more painful it is to work with it.

For programmers complexity results in:

• lack of motivation,
• pressure to output more than they can,
• unfulfilled desires to learn new technologies and improve skillsets and
• ultimately in checking out pilling offers from recruiters.

And for the rest of the company it results in:

• delaying launch plans,
• having marketing and sales teams on standby,
• customer support teams gathering the same bug feedback from clients for long periods,
• high rotation of “unskilled” developers and
• a hard time keeping up with competition.

However making sure the codebase is easy to work with is rarely acted on. It’s more commonly the kind of thing that gets attributed a lot of conversation time in the form of frustration release and hopefulness.

And it is true, simplifying the codebase does not output anything tangible to end users, not directly at least, but it can easily increase productivity by easily more than 2x in most cases, and by more than 10x, in extreme cases.

So firstly let's try and identify causes to this problem:

What is bad code ? And how does it affect.

Complex to set up 🕐

The first impression a coder has of a project is setting it up on his computer. Some people say that first impressions are the most important when meeting someone, many coders feel the same with projects.

It’s surprisingly common to hear stories of world class contractors taking weeks setting up their development environment. That’s time where nothing is outputed at all, not even making the project simpler, nothing!

Hard to Understand 👽

If a developer:

• requires close constant support from whoever wrote the original code to understand it or
• takes a long time understanding what to change/add/remove in order to complete whatever task he has,

odds are the code is hard to understand.

This problem can cause great frustration to both coders and employers since the output from the developer is only a small % of what it could be.

Bureaucratic 📃

None of us like pointless tasks, neither do coders. But when code starts piling up on “Hacks” tasks that usually require few steps can easily multiply proportionally to the amount of “Hacks”.

This causes a drop in motivation and if the coder is not allowed to simplify the project’s complexity it might create a culture of being ok with slowness.

Has many compromises 🔒

Another form of “Hacks” are solutions that tie the codebase to dependencies that can come in the form of code packages, Operating Systems, connected running processes (locally or online), software versions, etc.

Compromises lock coders on techniques and technologies that reduce their productivity and are known to cause more problems than benefits.

Advanced 😥

Saying code is advanced is a very common hiding place of developers that prefer to not be bothered by justifying their decisions.

No matter how amazing the end result, if it’s not easy to understand by others it will never scale or it will die. Since no developer that can work with it can be found, after a long process of hiring and firing developers that ‘were not as qualified as they seemed’.

What steps can be taken to prevent these problems ?

Have a good project base 🏕

The base of a project is something developers will have to interact with and understand deeply every single time they wish to do anything with it.

It can be summed up to:

• development and production environments
• architecture

It’s not a lot, right? Well… It shouldn’t be, I think it should not take a developer more than 5 minutes to understand the base. However it’s very easy for the base to get complex.

Over Complexifying the base happens because of being in a rush. And I do agree that taking a long time on making sure something is done the best possible way is not effective. But don’t rush just the base. Rushing individual parts of a project is absolutely ok, the less they are dependent on by other parts the more ok it is. 
In fact, individual parts of a project can be completely different from the base architecture, as long as the deviation from it is well documented at their own level and have no impact besides at their own level.

The idea of a base is to help developers have a pattern on how to do things, that way they get to think less on how to add complexity to a project and where to find it.

Promote recyclability ♻️

As proud as we can be of our solutions, it’s healthy to understand that they are only relevant until newer ones are found.

So when writing code, it’s a good idea to make it as simple and independent as possible. Since when better solutions are found, code that follows these values can more easily be used in different contexts. Which reduces work on migrations and allows for a bigger choice of development tools.

Be social 🗣

Asking other developers what they think about ideas can help find bad patterns early on.

This is especially important when setting up the base, as making changes to it later on might involve unrealistic amounts of work.

Be lazy 😴

If you find yourself repeating tasks over and over don’t just keep doing them. Instead find a way on how to automate those tasks or simplify the project base.

If you do automate the bureaucratic tasks also document the new commands as part of the development environment commands. So that anyone working on the project can also have a better experience.

Simplifying the base can be time consuming, but again, it might also save enough time in the future to make up for it. And the more the project grows the harder it will be to simplify.

Concluding

Good code is the most important factor for:

• the longevity of a project,
• scaling the amount of people working on it,
• how many features it can hold and
• development speed.

It requires:

• good taste,
• a good base structure and guidelines,
• to be developed socially by lazy developers and
• to be as independent from dependencies and as easily replaceable as possible.

Keep in touch

I write in the interest of meeting people with whom to have interesting conversations with. So I would like nothing more than the get a message from you.