You’re a software engineer working on a project and you keep coming up against roadblocks of how the code is laid out. You’re spending a ton of time trying to force the code to do the one thing, and it feels like it could be a lot easier.
Being a good software engineer, you’re going to reach for your most trusty tool in your toolbox: the refactor.
Your manager has all kinds of super important TM deadlines and they don’t want you to do this. They’d rather you just get that feature they need want out the door.
How do you get them to say yes?
About twice a month, I’ll get someone coming to me to ask for career advice. I’m starting to collect the more common questions and my thoughts on them. I’m putting these together as a series of blog posts under the tag CareerPlusPlus.
Why they want to say no
There’s all kinds of reasons managers are hesitant to approve code refactors. Here are some of the more common ones I’ve seen and I’ve given.
- It’s not necessary.
- It will take too much time.
- The new design isn’t better.
Why do we/they say these things?
If we flip the table and try to think of it from the manager’s perspective, they’ve got all this work lined up and deadlines they need to meet. When you do a refactor it means you will go some amount of time with no direct progress towards company goals. That doesn’t mean it’s not worth doing, but it is an important consideration.
If you do this job long enough, you know the refactor will probably also cause regressions.
If you think the changes you want to make can’t possibly be grounds for the concern about regressions, then the refactor you’re suggesting must not be that big of a deal and you could have done it without asking. If you need enough time to do this change and you can’t identify the regression risks, then it’s time to rethink the problem. Run it by another engineer who is familiar but not working directly on it. Maybe they can help you identify the risks. I’ve been doing this a long time, and I’ll bet you there are some.
Why do the managers think it’s not necessary? That’s because it’s either (A) not actually necessary or (B) not clearly communicated the value it will add. I’ll address this in more detail below. Suffice it to say that in the mind of the manager you’ll be spending hours without sufficient benefit.
What if they think your new design isn’t better?
At this point, I think it’s time to take stock and try to ask yourself without ego if they may be right. Or take away the binary yes/no and try to think of the ways in which they are right and the ways in which you are right.
Run it by another engineer or a rubber duck.
Know Your Why
If you’re an engineer and you’re reading this, you probably have somewhere in your mind an idea of why the code needs to change. It may be super obvious to you. You’ve been staring at it and banging your head against the table.
You’re in the best possible position to explain in very simple terms why this is a good idea. But you have to sell it. If you’re going to sell it, you’ve got to believe it.
Here’s the actual recommendation: Come up with two distinct specific use cases where your refactor is going to make an impact. One should be short term and one should be long term.
Honestly, it’s really that easy.
What I hear instead is “Well if we do this then it’s going to make it easier to write some of the new features we want.” That could mean… anything. That doesn’t actually convey any real message.
“We can write feature X in half the time.”
NOW you have their attention.
“It enables feature Y. Without it we would have to do alternative Z.”
Seriously, just steal these words and replace X/Y/Z with something very short. Keep it punchy. Impactful. Shoot for one sentence. Trust me, they will ask you for more if they want it.
Now back it up with 2-3 punchy sentences that get to the core of what you’ll need to do to make it happen. “To do this, we want to switch the code to using the observer pattern. It’ll take about 3 weeks and we can do it in 4 phases.”
Share it out
Again, I’m going to suggest you phone a friend. Grab someone who is familiar with the code and tell them at a high level what you want to do. You should be able to use your words, but sometimes a diagram will be helpful.
Diagrams should not require glasses to understand. You’re trying to sell the idea not the implementation. Keep the thing you show them a high level, but have the specific ideas ready for when they ask.
Solicit input. Many times you’ll find someone else’s perspective can greatly improve your ideas.
Also, take a look at the Gang of Four design patterns. If you’re not following one of them, are you making a new one? Is that necessary? Is it appropriate? Those patterns exist for a lot of good reasons.
Closing thoughts
It can be hard to convince people to give you the time/money to do the engineering work you think is necessary. Sometimes you’re right. Sometimes you’re wrong. Sometimes you’re right but there isn’t the ability to do it based on external circumstances.
If you have a good idea and you can clearly communicate how it will make impact and you’ve clearly thought about the risks, you’ll move yourself a lot closer to getting that thumbs up you’re looking for.