How to Convince Someone to Refactor their Code?

spaghetti code


“Why fix what ain’t broke? “

I’m sure all of you must have heard that saying one time or the other. Sometimes it works and sometimes it doesn’t.

It definitely doesn’t work when an application kinda works but has been built on a quagmire. A big ball of mud, you see. It’s a development team’s nightmare to keep the system humming and enhancing it. It’s mentally exhausting for developers to figure out all the impact areas before they add or change a single line of code.

Truth be told, it’s demotivating.

It’s demotivating because it makes the developers somewhat powerless as they don’t have much clue regarding how the system would burn in flames the next time. Also, they feel powerless given how long it takes them to do a simple friggin’ change in that application.

So, what are the options?

1. Scratch the current code base. Wipe the slate clean. Gulp lots of Red Bulls. Roll up your sleeves. Write the new system.

2. Refactor the code – Module by Module. Component by Component. Layer by Layer. And, Gulp lots of Red Bulls.

I believe #2 to be somewhat sensible(your mileage may vary) as there is so much knowledge that is already baked into the product. It just makes sense to refactor the code.

Now, the burning question, how do you convince someone to refactor their code or the application?

I could go on writing more about it, share facts or show someone the below picture – Reasons to Refactor your code


Happy Refactoring.

You might also like