OmbuLabs Blog

“If you can’t measure it, it doesn’t exist” - Peter Drucker

Tackling technical debt can be a thankless task. You can spend hours tidying up old files but at the end there’s little to prove it was a good use of time. No target was met and no new feature exists to show the bosses.

The lack of metrics means that maintenance tasks gets pushed back behind work with obvious outcomes and the debt keeps building.

To make matters worse, the costs of technical debt are also hidden. Projects will start to overrun and developers will get burnt out, but there’s nothing clearly showing that tech debt is the reason why. It means maintenance starts to feel like a chore with no obvious outcome or benefit.

We have had to come up with ways to show the value of our work when performing maintenance for clients, so we wanted to share them here to serve as inspiration for other developers.

The impact of technical debt is obvious to developers. Devs are the ones that have to tackle the headaches of dependency issues and patch holes in the security.

But the reasons for performing software maintenance can get lost in translation when they’re discussed with non-technical executives. It can be unclear how rewriting functioning code can translate into more money in the bank and why it’s worth dedicating time to.

So, here’s how we describe the business reasons to prioritize your maintenance.

Getting started with a new project should be as simple as possible, even for someone who is not technical. As a maintainer, you must make sure that anyone can clone your project and get it up and running in a few minutes.

After you clone a project, you should follow two steps:

1. Setup
2. Start

It will come a time when you will have to decide whether to maintain a Rails project or not.

If you want to seriously consider it, you should follow these 10 steps:

1. Setup the development environment

Git clone the repository and try to start the server. Is the README clear enough? Can you follow the steps in the file and easily get started?

A lot of projects will have a README that is out of date and/or instructions that don’t work right off the bat.

Most of the projects will define guidelines like these:

• Configure your config/database.yml
• Configure your .env file
• Setup the database rake db:create db:migrate db:seed
• Start the server rails server

The best projects will have a one-liner that will setup the entire environment for you.