This article has also been published here

I have been working in the IT industry for a while now, and I’ve seen my fair share of code. And there is definitely a pattern that I have seen across companies big and small…

Let’s just say, you start off with all the best intentions.

• We will use the SOLID principles
• We will make sure we have close to 100% test coverage
• We will make sure to work on the features that have been agreed upon
• We will make it easy for new developers to come on board so they can start working immediately

You start off with a militant regime of strict code reviews. You may come off as quite anal when you start requesting changes when you see a bit of extra whitespace on the page…that isn’t the standard we are following.

You start off with discussions about requirements. You lay them all down on the table so the client can start prioritising them. And then you start building stories for these requirements and adding them to sprints, because you have decided that agile is awesome.

You start off assigning the tickets to the developers, designers and testers. The feedback loop is amazing, and it feels like you are getting a heck of a lot done! Tickets are flying around the board 🙌

Congratulations, you’ve built your product

So the product is built. Users have been signing up left, right and centre. You have been getting feedback from them asking about new features, or maybe they’ve found a bug that needs fixing.

So you need to go back into the project… 🔍

The fork in the road

Now here is the crucial moment in the life of your codebase.

One path leads to continued joy, and that you know will mean you can keep continuing to release new features quickly and efficiently.

The other path leads to quick fixes, workarounds and hacks that incur a bunch of technical debt.

Listen…I know you don’t intentionally want to make it harder to work on a codebase. But once your company is successful and you have more and more developers working on your codebase, it becomes quite difficult to continue to enforce the standards you had at the start of the project. This could be due to:

• Urgent bug fixes that need releasing ASAP
• A new feature that was introduced broke a bunch of stuff, so new code needs adding to mitigate issues caused by that feature
• Tight deadlines!

Treating your codebase like a garden

I remember going to the North West Ruby User Group a while ago and hearing an amazing talk by Ceri Shaw from FreeAgent. The talk was titled Cultivating Code, and was about her discovering that writing software was a lot like planting a garden.

Now I have never thought of that analogy before…but it really makes sense!

What can we learn from Gardening?

Picking the right tools

It should go without saying that you need to decide what tools you are going to use to get the job done. For example — you wouldn’t need an axe if you only want to plant some flowers 😅

So what tools do you need before you start creating code?

• A development machine
• An IDE
• A plan (even gardeners need to know what they are working towards)

Although I mention IDE above ☝️, you can most likely get away with using some smart text editor like VSCode or Atom.

Picking the right tools is crucial to your project. It makes things simpler. And simpler things are a darn sight easier to work with.

Picking the wrong tools will no doubt end in frustration and will not be good for developer happiness. Productivity will suffer as you try and get to grips with tools that are not suited for the task you are aiming them at.

Planting the seeds

You’ve made your plan, and you have selected the tools you need. Now comes the best bit of any greenfield project.

Now you get to plant the seeds 🙌

Now hold on a second…it is easy to go full steam ahead and start writing code. You need to stop for a second and think towards the future!

1. Shall I use a framework? Or am I going to write everything from scratch?
2. How do I organise my project?
3. How big is this project going to get?
4. How complex is this project going to get?

Most of this could be answered in the planning stage, but quite often it isn’t. Planning often consists of what the project is for, and what the final (or MVP) product should do. The planting stage is where developers can start working out what additional tools they can use in order to get the job done.

All of the points I have raised add up to one thing. Making it easier for another developer to hop onto the project and begin either bug fixing or adding new features without having to think too much. For example, using a framework may be a lot easier to work with than trying to brew your own. The documentation will already be laid out (depending on what framework you choose 👀), and that makes it a breeze for another developer to pick up.

Also, projects very rarely remain simple. Complexity comes in varying flavours, but so long as you can keep those complexities isolated in their own burrows then you can keep the rest of your codebase looking beautiful.

Watching your garden grow

The project is going great. You’re plan is going perfectly. Working in an agile way is definitely producing some great results. You have a constant feedback look that is ensuring that you are delivering exactly what was promised during every planning meeting.

Although you’ve taken a step back and left the other developers to work on the project, you feel safe in the knowledge that progress will still continue at a consistent rate.

Everything is beautiful 🌻

Actively maintaining your garden

Nothing stays beautiful forever without a bit of work. Maintaining your codebase is no different. There will be bugs (if you’ll pardon the pun) that try and worm (and again) there way in. You’ll need to maintain the flow of having rigid acceptance criteria and rigorous testing to ensure that any unexpected behaviour is caught at the earliest possible opportunity.

Actively NOT maintaining your garden

Failure to relentlessly maintain your codebase will result in undesirable additions being able to creep in. And it is a slippery slope. I often picture this as an if condition that has gone out of control. You know…the ones that have a heck of a lot of nested conditions under them. It even has a name…the Arrow Anti Pattern.

Sometimes the easiest change incurs the most technical debt

How do you stay on top of your garden?

I think the key to keeping on top of your codebase is to plan any changes that you want to make. Try not to get into the situations where you have tight deadlines. During planning meetings it is vital to communicate if something is going to take a little bit longer. Stress and pressure often leads to complacency. That can lead to developers writing code that is hard to understand. And the double whammy for that is that code that is hard to understand is the perfect breeding ground for bugs.

Also, it is vital you don’t create too many changes in one go. Gardeners ensure that they are working on a single area to make it perfect before going on to a new section. This ensures that their full attention is on the task at hand. As a developer it is easy to get drawn away to another more pressing matter, and there have been many discussions about the damage that constant context switching can have on developers. Getting into a frame of mind to tackle a project can take some time, and then to be taken away from that problem undoes all the preparation you have just done.

To ensure that a project is always following the standards you should have a product owner who is not afraid to speak up if a developer is starting to diverge from those standards. This can be managed by performing code reviews before any new code is added to the main codebase. If you feel that a developer is still not following standards, then perhaps a paired programming session could be the next viable option.

I am sure there are more ways that you can keep your codebase looking as fresh as the day it was created, but I think the the ones I have mentioned above are the most important.

I hope this has been a valuable read, and I look forward to hearing any feedback 😄