Refactoring Reasoning for Non-Techies
Even non-programmers will be able to understand why it makes business sense (and developers' lives easier) to prioritize refactoring.
Join the DZone community and get the full member experience.Join For Free
Developers come to work each day in the hope of refactoring. That's right! Every developer reading this that has worked with crumby code is nodding their heads right now. I'll explain why that is, but I want to make the case that it is absolutely in the interest of an organization to prioritize refactoring into every iteration you do.
I’m going to try to illustrate the reasons why without resorting to any code. Non-techies are welcome here. If you don’t understand what refactoring is, fear not; you will soon.
Let's imagine you are a Manager, a Product person, or maybe a Stakeholder at Big-Awesome-Co for a moment. You work alongside (the nicer way of saying "above" or "over") a team of developers who get through a reasonable amount of work per sprint. But you know they aren't satisfied with their jobs a lot of the time.
They say the code is “confusing, “misleading” and “bloated.” They say there aren't enough tests. Maybe they say they need to rewrite it. They might be right. More often than not though, it's more of a red flag that refactoring isn't happening.
Why is refactoring code so important to developers?
What We Want: Clarity of Intent
We’ve all received a rushed email from someone that doesn’t make any sense. Sometimes the email is of a critical nature and you’ve got to work with it. You feel like shouting “I don’t even know what that means!” It’s no fun.
But code doesn’t work that way though does it?
I’m afraid it’s not that simple. Let’s see why.
The Code Is Confused
Read this sentence aloud for me.
“The complex houses married and single soldiers and their families.”
That sentence is grammatically correct. But it’s really confusing, isn’t it?
It’s a special kind of sentence called a "Garden Path Sentence." They’re fun little distractions, but not so much fun if you have to decipher them all day, every day. Read it again, it makes sense I promise.
Still haven't got it? Try this "refactored" version:
"The complex houses married and single soldiers, and their families."
It means that single soldiers, as well as married soldiers and their families, are housed in the complex. Code can be written in a way that works, is syntactically correct, but is still confusing as hell. If they say the code is “confused,” This is what they mean. Let’s try another.
The Code Is Misleading
“More people have been to Russia than I have.”
That one makes sense, right? Except it doesn’t.
This is an example of something called the "Comparative Illusion" (sometimes called an Escher sentence). At first blush, it looks like it makes sense. But it does not. Go on, try to make sense of it.
Code can be written in a way that looks right, and is simple, but does totally the wrong thing. If it was our actual intent to say, “People have been to Russia more than I have,” we could refactor it to say that. If they say the code is “misleading,” this is what they mean.
Okay, last one.
THE CODE IS BLOATED
“The young male rats that were from the same colony as the rats with symptoms of the disease, but which do not show signs of the disease at this stage of their development, were used as the control group”
This one makes sense and is grammatically correct, but it’s a bit of a mouthful, making it hard to wrangle into a coherent thought. Let’s rewrite it.
“The symptom-free, young male rats were used as the control group. These rats were from the same colony as the rats showing symptoms of the disease.”
This is the most common one we encounter as programmers. It’s an example of something that started out simple and became more complex over time by adding extra clauses. We can refactor the original sentence by separating the two statements and make it easier to work with and understand.
If they say the code is “bloated,” this is what they mean.
Conclusion: What Are You Paying For?
Okay, let your brain take a breath for a second. Those kinds of mental gymnastics is really tiring, aren't they Nobody in their right mind would want to do that all day long.
Do we really want to invest our hard earned money in puzzles like that? Or do we want software that is easy to understand, maintain, and extend?
Every time we say there isn’t time for refactoring, we force people to spend their time picking apart code and trying to figure out what in the hell it’s supposed to do.
That is a really bad investment.
Every new feature will be harder to integrate. Every bug will be more difficult to fix. Eventually, you will grind to halt. And that’s what makes refactoring a business problem.
Favour clarity in design. Prioritise refactoring.
Opinions expressed by DZone contributors are their own.