Why leadership didn’t keep their word and how you can convince them to do the project your way

You’ve finished a project which was completed in a rush but you reluctantly agreed to cut corners so you can meet the deadline, with an understanding that you can do it better later.

Now the deadline has come and gone, you want to fix the project up. You want to refactor and reorganise the code so that it is maintainable and easy to expand in the future.

However, your manager says: “I need you to work on something else now. Fixing this project is not a top priority, we need to work on X instead.”

As an engineer, you might feel betrayed, or lied to, and you might just be tempted to say to your boss: “But you promised we can do this after the deadline”. What just happened? Why is your boss not keeping their word and making you lower your code standards like this? It seems awfully unfair.

Here’s what happened

Your boss is probably measured by how often they release projects when they say they will. Going over old code is no longer a priority, unless it causes delays somewhere else (and therefore impacts on their targets). They also trust you to do an excellent job. And because they have faith in your coding skills, they often don’t realise if the code quality is good enough or whether it will delay other projects. You are the expert; you are the one who can help them understand how valuable it would be to them (not to you!) to let you go over old code. Going back to improve the code has to solve a business problem, not a promise.

Instead of trying to appeal to promises, tell your boss something that is high on their list of priorities: time, efficiency, proper use of resources (staff time).

Here’s how to convince your boss to let you go over old code

Instead of arguing with your boss about what they did or did not promise, you can say something like this:

1. Describe the problem your boss cares about:

“We’re wasting 70 hours on working around issues. I have an idea how we could reduce this feature delivery time from 120 hours to 50 hours. These are the bugs that we have found that have depended on this area of code, which we rushed to get done, so we could reach the 1 March deadline. These bugs would not have happened if the code was written well initially.”

1. Tell them the cost (in time and/or money) the company already expended and the cost to the company if you don’t put this old code right. Tell them why it would take longer to do this new project without working on the old code.

“Our team spent 20 hours fixing these bugs because they were preventing us making the new feature work properly. We’re likely to spend another 70 hours just because of the poor quality of this code, because we keep having to stop to fix it at every step of building this feature.”

2. The solution — Tell them what you would like to do instead of what you are doing now.

“It would take us about 20 hours to repair the old code. This would mean, that, after the repair, we could finish the features for this new project within 30 hours, instead of 120 hours. This would save you 70 hours, and we could finish the project in 50 hours, by this month, not next month.”

As an engineer, to convince your boss to let you do what you think is right, you have to make the problems that are obvious to you, problems the company can understand. They don’t understand the code, but they understand time. Time is cost to the company.

The more you can use statistics, the better. Code churn statistics are a great way to show that this poorly executed code is causing delays. If an area of your code has changed a lot, it means it is a critical area of code, which impacts the development of other parts of the project. If this area is of poor quality and the code is changed frequently, you have bad code and you keep going back to it to repair it. This wastes time. If it would be quicker to fix the code once and for all than to keep going back, and you describe this to your boss, they will agree to let you fix the old code.

If you want to go over old code just because there some niggles exist that you can’t stand knowing are there, you might not have a case to convince your boss to let you spend time on this, especially when they have other deadlines. What problem does it solve for the business to let you sort out those little niggles in the code?

At the heart of convincing your boss to let you do something is this: does it save the business money and time, or is it just a “nice to have”? If it’s a nice to have, and it does not add real value to the business, regardless of how nice your boss is, it’s unlikely they will agree to you spending time perfecting lines of code which have no impact on other projects.

What other examples do you have that helped you convince leaders to do the project your way?