Sick of the R word

| 4 Comments

I'm getting a bit fed up of hearing the word 'Refactoring' when what people really mean is just 'hacking at code'. Back in May last year I responded to Bob Cringely's piece on how bad the whole idea of refactoring was; I still stand by what I said and, looking back, I think the key point is this:

"Not all code changing is refactoring. Refactoring requires discipline. You need to balance the risk of refactoring with the risk of not refactoring. You need to know when to stop and you need to do it because it's the right thing to do for the project, not just because you can. Changing code without this kind of thought and discipline is just hacking (in the worst sense of the word)."

Unfortunately, now that 'Refactoring' is trendy, everyone refers to every little hack job as 'Refactoring' because it sounds so much cooler to management... I think that's a pity; it devalues the term. When Refactoring is done well it improves the quality of the code base; when every little change is 'Refactoring' then it has at best a neutral effect on the quality of the code.

4 Comments

I think refactoring is just a name for something we've always done as software engineers. There are certainly a lot of times that I don't totally understand a problem before I implement the first version, possibly in its own branch. Once I see the logic working, the interface often becomes more clear, and it is "refactored" into a more consise abstraction. I don't believe those modelling proponents that say they can figure it all out in advance. Even if they do, I'd argue that it often takes longer.

I think Cringeley is wrong here. Large scale software development, if anything, is about interface specification and communication. While my first version may work, the refactored version, has more long term legs.

With that said, what I think happens, especially with junior developers, is that they refactor code for the sake of refactoring. Often times the result isn't an improvement, it is just different, and possible worse in other ways. I honestly believe that the concept of "good enough" is something you learn with time. And there are plenty of times when "good enough" is "good enough," especially when the logic has been tested and shown correct.

One Open Source project that drove me nuts with constant refactoring, or hacking you might say, was Jakarta Turbine. The interface was constantly changing, and often I didn't see the benefit. I eventually went to one of the development meetings, and realized there wasn't anybody senior enough to lead the project, and I stopped using it. I did learn a lesson. Not all Open Source project work.

Christopher,

I agree, I still stand by my response to Cringely and feel that mostly refactoring is just 'not stopping until you're done' (ie finishing work by cleaning up the piece of code that you write that can do the work into something that's production quality) and 'knowing when you need to restructure before making changes'. The TDD stuff is just the first point taken to extremes by pointing out that you can do something really simple to get the code to work because you can adjust it as new requirements come along...

What I object to is the way lots of people use 'refactoring' to refer to ANY code change they make. Such as the project I'm helping with right now where the 'refactoring' was more a case of the guy taking something big that worked but was very ugly and taking 3 weeks to hack it around and be left with something completely different that doesnt work and is very ugly. That's not refactoring ;)

I guess the key point is that I view refactoring as a series of controlled transformations. You can do lots of these transformations in series and it looks like you're making big changes, but it's really a series of small changes; and, mostly, those small changes can be confirmed as good at each stage. I suppose it's an experience and fear thing. Inexperienced developers dont know enough to be suitably afraid...

I think lack of management of developers is one of the biggest and most common problems I come across. People are just left to get on with it and management hope it works out. It sometimes does. However, since often the level of experience of the people involved isn't really understood by management and since the less experienced people are more likely to overrate their level of experience and make "bolder" changes it's not surprising it often ends in tears.

> Inexperienced developers dont know enough to be suitably afraid...

True True! I love that. I speak from experience here ; )

One thing that takes years of practice is the ability to go into a large code base and make modifications with out screwing things up. I think the instinct of many inexperienced programmers is to rewrite stuff they don't understand. This is almost always a bad thing.

Many times code looks complicated because IT IS complicated. You have to respect the code. Maintainence programming is probably one of the most difficult things a programmer can do. It is under rated.

> Many times code looks complicated because IT IS complicated. You have to respect the code.

I think that depends on the codebase. I've probably seen more code recently where it's complicated because it's poorly understood rather than complicated because it's complicated. But that may just be the clients I've had recently.

> Maintainence programming is probably one of the most difficult things a programmer can do. It is under rated.

Agree. It's interesting to see that whilst inexperienced people are often happy to just leap in and 'fix' things, for the reasons you mention; experienced people are often unable to fix things for the opposite reason. Some teams just seem to freeze up, they cant/wont fix things that need fixing and that would benefit them long term because they're just too afraid of changing anything because they assume there's a reason for all of it... Often there is, often there isn't...

Leave a comment