Refactoring Code: Why We ‘Fix It Forward’ For Your Project

When you’re choosing a development agency, how often do you consider code quality? For us, development work tends to break down into three areas:

1. A business has an idea for a digital product but no code has been developed, so we are able to build from scratch.

2. A project where we are already working with the business and are maintaining it.

3. A ‘brownfield’ project which has existing code and development work when it comes to us.

While we take a different approach to each of these types of projects, one thing remains true throughout - no project is ever truly complete, and refactoring code should always be considered as part of the development work from the outset. A great developer is one who aims to create code that can be updated, upgraded and worked on in more efficient ways.

Unfortunately, not every team thinks like this. Some of the brownfield projects we are approached with have such poorly architected and written code that we either have to be pretty plain with you: we either rewrite it from scratch, the work will take longer than expected or we won’t be able to do the project.

Basically, this means that projects that haven’t already had a history of refactoring and good coding practice are going to cost you more in time and money.

Fixing it forward with refactoring

What is refactoring?

When we say ‘fix it forward’, we mean building projects in a way that ensures they can be updated and maintained in the future after the initial launch.

Refactoring is the process of updating and amending code as a project develops. To do this successfully, the development team must ensure that any code built is made clear and understandable. This requires automated tests, documentation and the intelligent application of automation tools such as Linter and Jest which can assess code quality.

Often we receive a project that when first inspected ‘looks good’, but upon further investigation and testing reveals issues.

These problems could be performance-related, security issues, or it could simply be the project has been "over-engineered" or is hard to work with as a developer.

This evokes the ethos: don’t judge a piece of code by its syntax.

Like we said earlier, unfortunately, many projects that fall into our laps come with poor code. This means no refactoring has been done, and the code must be either reworked entirely or tweaked heavily and increase the overall project timeline.

Ongoing refactoring should be something every development team does. When you choose to work with KOMODO, you’ll be benefitting from that exact mentality: we don’t mess around - our code is good enough that it could be brought in-house or (hopefully not) to another team if we stop working together.

We do this not to impress you as a client, but to raise the standards of the industry in general.

But let’s face it, why would you want to work with an agency that didn’t refactor properly and end up with code that is too complicated or difficult for any future teams to work on?

Code Like KOMODO: Our refactoring approach

Good refactoring is about looking at the code/project and considering what it is trying to achieve.

Like our pitch approach, we don’t just look at how a feature/project should work, or what a string of code looks like - we try to examine what it’s trying to accomplish. We also assess how maintainable the code is - is it something another developer can pick up and work with? Code should never be exclusive to one person or you face a disaster scenario if they leave your business for any reason.

When a project begins, we either build it from scratch or inherit code. If inherited, we will run it through a series of tools to give us an idea of what shape it’s in.

And if it’s rough, we’ll tell you. We’re not going to mess around - bad code means more work, so we’ll be plain about it from the get-go. Sometimes it’s better to throw the whole thing out and start from scratch rather than spend the time it’d take to fix it.

A common issue for inherited code is a ‘code smell’, where a developer has accomplished a solution but in a bad way, which means the product may do what is intended but not as efficiently as it should. While every project has some degree of code smells, the issue begins when there are lots of them.

Even here at KOMODO, we are not aiming for perfection - code just needs to accomplish a task efficiently. If you approach us for a proof of concept, we’re not going to create ‘perfect’ code, we’re going to create code that does what you need it to do and can be worked in iteratively through refactoring.

Does your code stand up to our test(s)?

Many of the projects that come to us with existing code do not have automated tests built into them. This means a new developer can’t have confidence in the project as they can’t use tests when implementing new features - which could mean making changes that break the entire project.

We recommend that testing is included in every project - which can increase the time and cost of a project, but ultimately delivers a more stable and sustainable result that will make future updates easier. 

Manual testing is also a possibility - often used when we can’t create automatic tests in inherited code and instead have to get our team to perform tests regularly to assess the impact of changes.

This is all done to build confidence for the development team, whether that’s us or you - the confidence to trust the code to support its own tasks: can it support X number of users, can you trust that it won’t be vulnerable to security issues, can you trust it to be worked on by future developers?

These are the questions that testing allows us to answer.

Refactoring Code = Future-Proofing

Whether we’re building from scratch or working on inherited code, we are always working on the assumption that it will be KOMODO working on the project forever, which helps instil the practices that keep code and the project in a workable, constantly refactored state.

We build test suites as standard, so developers can test and change and edit without fear of breaking anything. We document our entire process and use the right type of documentation - for example, we won’t just write reams of notes for an API, instead, we use API-specific documentation which allows you to test the API’s implementation etc.

Our approach to documentation is simple. We outline what is needed through simple questions:

• What do we need from the documentation?

• Who is the documentation for? A seasoned API development team doesn’t want walls of text.

• How extensive does the documentation need to be?

Remember: documentation is as useful to our team as it is to you, the client. Without it, our own team members couldn’t pick up other people’s work or use it to avoid causing errors. Your team, if you choose to take the project in-house or we’re only developing a sub-section, can use documentation to avoid missteps and make ongoing updates and maintenance simple.

Example in action: documentation keeping public data secure

One of our clients deals with sensitive public data, so their software must be kept constantly updated but also secure. We work in sprints where we document everything worked on in that sprint, which members of our team did the work and what problems occurred.

All of this information is then added to the client’s secure internal documentation portal, which allows them to hold all of the documentation securely. We create project flowcharts using LucidChart to visualise any changes ahead of actually coding.

Coding the right way from the start

Code is never really ‘complete’ - but it must be workable for future updates and additions.

The more automated tools, tests and documentation built into a project from the outset ensures that the development team, whoever that ends up being, can have confidence in the code itself.

To make sure we adhere to this, we’ve even created our own in-house scoring system to quickly assess any existing code projects we are approached for. While we sometimes turn a project down, usually we’ll be able to use our checklist and assessment tools to give better time estimates towards fixing old code.

To you as a client, this may seem like a bad thing: wait, they’re not even going to build what I want until they’ve done all those hours refactoring code? But without it, your project will be unstable and easy to break, as well as critically exposed to security threats and updates that can break functionality.

There is no set standard for what must be done on existing code. Often we can just work on new updates and do a small percentage of work refactoring old code as we go. But the important thing is that we deliver a project that has code we’d be confident in our own team using for years and years.

For clients, this means a massively reduced risk. You’ll see quickly that not only do we know what we’re doing, but that any internal team or future new business partners you want to work with can also interact with your code. You won’t have to fork out in the long term for complete overhauls.