You’re a manager, and your developer tells you they want to refactor something? You’re a developer, but don’t know if you should resist the sudden urge to refactor that ugly piece of code you just saw? Here’re true stories that will help you decide.
Useless luxury
A long time ago in a galaxy far, far away… I had to implement a really complex subsystem for our project. Our users were quite picky and had a lot of requirements, and the logic was very convoluted. But it was absolutely necessary for them to have it in exactly this way, with all nuances.
So I’ve done all that. I wrote the code. I wrote tests, the code passed code reviews, it was tested by QAs, and it was published to production. It worked. I took care of all user requirements, of all their habits, of all complex scenarios, and of all tricky cases. Users were happy, and I was happy with them. And I was proud, of course.
A couple of days later my colleague told our team that my subsystem was written very badly and he’s going to take a couple of days to rewrite it completely.
I was abashed. Did I do all this work for nothing? Did I really create a bad thing?
My colleague had much more experience than me, and he was so sure of himself. So I believed he was right. Well, I was just a young developer, I needed to learn from more experienced ones, so if he shows me what I should’ve done in the first place, I’d be grateful.
So he started to refactor.
After a week he gave me his new code for a review. In an hour of clicking through the UI and looking through the code, I found out that he didn’t take care of all these tricky things of which I cared so much. I wrote about it in the code review.
He fixed some stuff, and gave me the code back. I found more things.
After one more week of moving it back and forth we were back where we started from. The only change that was left from the refactoring was a couple of class renames.
And it took two weeks.
Life-saving necessity
Many years later, in a different galaxy and in a different project I was working on, we found out that we display inconsistent information to our users. If we were selling electronics, we would display that a vacuum cleaner has 10Mpx camera resolution. I’m talking an old-fashioned vacuum cleaner, not a smart one, of course.
Our customers were calling and complaining. Some insisted on money return. Others were asking if it’s possible to post photos of their clean floors directly to Instagram, and if they could skype their mom while vacuuming.
So I started to tell everyone we need to refactor and fix that.
The managers in this galaxy weren’t so keen on allowing developers the luxury of refactoring. But I managed to convince them, and we implemented the changes. Now we could set and display only relevant attributes.
Reasoning
Sometimes it’s hard to understand whether The Big Change is really needed. In some cases, its absolutely necessary. It simply can’t go on like this, when:
- When the current code doesn’t let you implement new features. It’s too complicated, or too rigid, or too fragile and breaks. Every. Damn. Time.
- If there are bugs. Bugs should be fixed. Sometimes it’s a small change, and sometimes a big one. Big ones usually lead to refactoring.
- You have free time and want to improve something. A noble reason :).
But there’s a number of things you should consider before refactoring, or before agreeing on someone else’s idea of a refactoring.
- Is there a real problem with the current code? If it “just looks bad”, it’s not enough. If it doesn’t let you do new stuff, or breaks often, or has bugs, that’s a problem worth solving.
- How long is it going to take? You don’t need a detailed estimate, but a rough one. Does this time justify the problem you’re trying to solve?
- Did you think of why the code was like that in the first place? Were there requirements you don’t know about? What are the chances you’ll break something you don’t know about?
- A logical followup: don’t forget testing the changes. It also takes time, and the found bugs could really turn a two-day pleasant journey into a two-week nightmare.
If one of these reasons made you doubt, maybe it’s worth investing your time into something more productive?
Use a pragmatic approach. Weigh pros and cons and decide wisely. I hope my stories will help you.
Have a fun time refactoring!