Stephan Schmidt

Too Many Developers Get Refactoring Wrong

What refactoring is and isn't


  • There exist big misconceptions about what Refactoring is
  • If you do the right thing, rewrites are minimal
  • If you also do some other things, have a tech strategy and tech vision and alignment with business strategy and business vision then rewrites go away

“We have to refactor” - words dreaded by every startup CEO—or CTO. Developers want to spend significant time on “Refactoring” the code, instead of writing new features. Growth is already behind hopes and investors are unhappy. Why now?

But Refactoring is a good thing, constant refactoring keeps the code clean, flexible and readable. What is this month’s long “We have to refactor?” Most often, it’s not Refactoring at all, it’s re-architecting or re-writing.

Too many developers get Refactoring wrong, and I’m not sure why this is the case. It feels like they’ve never read the Refactoring book but got their knowledge handed to them by generations of developers before them. When the Refactoring book came out anD I’ve read it for the first time (yes I’m that old), my mind was blown. There were coding tricks in it, I had never thought about before. Sure, some parts haven’t aged well, some parts haven’t been as useful as thought, and it’s overly optimistic about object orientation, but the core is still gold, and the book should be required reading for every engineer.

Whenever a CTO tells me developers want refactoring, its not refactoring but a re-architecture or rewrite. Perhaps they got mislead by the definition “Refactoring is a controlled technique for improving the design of an existing code base.” especially by the word “design.” But Martin Fowler follows up with “Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing.”'

Each of which is too small to be worth doing. There you are. But the idea of refactoring as a continuous flow of small changes to the code is lost and is replaced with sweeping changing to the architecture! We can’t do continuous refactoring, we have no time!

Let’s look at an example. The refactoring I like most is “Decompose Conditional” and says, “Extract methods from the condition, then part, and else parts.”

if user.isGoodStanding
  && len(user.orders)>5
  && user.hasOpenedEmail
  && len(user.email)>5 {
send(CouponEmail)
}

can be replaced with

if goodCustomer(user)
   && canSendTo(user) {
send(CouponEmail)
}

which is easier to read and understand. On top of that, goodCustomer and canSendTo might be reusable.

Last not least, the code is easier to test. While the first If might be part of some hard to test code, at least in the second If parts can be easily tested:

func TestGoodCustomer() {
user := User {
goodStanding: true,
orders: ...
}
assertTrue(goodCustomer(user))
}

With these tests in place, it is easier again to continuously refactor the code and keep it in good shape, which doesn’t get them in a mess and keeps a rewrite away.

You might think developers do all these refactoring, but then there is still some need to “refactor” aka re-architecture. My experience is limited, but whenever I look in a codebase that “needs refactoring” for an extended period of time, it didn’t have all the refactorings applied during development, e.G. many opportunities for “Decompose Conditional”.

This is how developers arrive at a messy code base and want a major refactoring.

But if they really need some rearchitecturing, still? How did developers arrive at a state where they feel that they need a “major refactoring” to change the architecture? They arrive at that state by creating the wrong abstractions, because they anticipated a future that never arrived. They want to remedy the situation by different abstractions again for a future they don’t know.

What to do instead: Keep abstractions in check. Be mindful and careful about abstractions. Every abstraction is an assumption about the future, and we’re not good at predicting the future (I would play the lottery if I were). So be careful with abstractions! They are the root of all evil, use them when you know where the journey is going.

Writing good code doesn’t take more time, I think, when I hear “We have no time for high-quality code” - which a lot of developers equal with deep abstractions. Writing code with ongoing refactoring doesn’t take more time either, it even makes you faster.

Writing side effect free methods as much as possible is as fast as writing bad code. Not hard-coding values are as fast as hard-coding them. Having the right size of methods isn’t slower. Thinking before you write code is faster than writing bad code and then debugging it.

For me, personally, engineering code quality as a red line, constant refactoring a must.

It’s the CTOs responsibility to help developers skill up. It’s the CTOs responsibility to create a professional engineering culture without shortcuts and bad coding. Don’t give in to pressure, keep your professional engineering up. It’s not easy for the CTO to give pushback on pressure, but it can be done—you’re not going to be fired. It’s the CTOs responsibility to draw the red line.

Join the AMAZING CTO newsletter!
By signing up I agree to receive your newsletters and accept the terms and conditions and data protection

About Stephan

As a CTO, Interim CTO, CTO Coach - and developer - Stephan has seen many technology departments in fast-growing startups. As a kid he taught himself coding in a department store around 1981 because he wanted to write video games. Stephan studied computer science with distributed systems and artificial intelligence at the University of Ulm. He also studied Philosophy. When the internet came to Germany in the 90 he worked as the first coder in several startups. He has founded a VC funded startup, worked in VC funded, fast growing startups with architecture, processes and growth challenges, worked as a manager for ImmoScout and as a CTO of an eBay Inc. company. After his wife successfully sold her startup they moved to the sea and Stephan took up CTO coaching. You can find him on LinkedIn or on Twitter @KingOfCoders

Other interesting articles for CTOs

Best books for CTOCTO versus CTOExperienced CTO CoachCTO CoachingCTO JobsCTO MentorCTO MentoringCTO NewsletterCTO RoleHow many developers do you need?Outsourcing Guide Technology and RoadmapsHow to become a CTO in a company - a career pathWork from home and remote with ScrumWaterfall and Scrum
Other Articles

Why we always end up with waterfall

Development Speed: From Idea to Release in One Day

Scrum is no longer fit with remote work

What Startups and Managers can learn from Brexit About Pay Rises And Customers

Startup CEOs learned Engineering Management from Captain Kirk