Mark Needham

Thoughts on Software Development

Consistency in the code base and incremental refactoring

with 6 comments

I wrote a post a while ago about keeping consistency in the code base where I covered some of the reasons that you might want to rewrite parts of a code base and the potential impact of those changes but an interesting side to this discussion which I didn’t cover that much but which seems to play a big role is the role of incremental refactoring.

In our code base we recently realised that the naming of the fields in some parts of a form don’t really make sense and I wanted to start naming new fields with the new naming style and then go back and change the existing ones incrementally when it was a good time to do so.

Richard and Christian suggested that this wouldn’t be such a good approach because it would make the naming issue even more confusing until all the fields had been renamed.

In order to avoid this problem we had to either go and change every single field to follow the new naming approach immediately or settle on the old names even though they might not be as descriptive.

Since doing the former would involve changing the names of around 15-20 fields across several different objects, in Hibernate mapping code, probably in the database, on HTML forms and in Watin tests we decided not to do that – the project is only for a short amount of time so the investment probably wouldn’t be worthwhile.

Although in this case it makes sense not to make the improvement it doesn’t strike me as being entirely satisfactory that we would need to make this type of change in a big bang fashion.

From my experience there are often insights into the code or improvements in the ubiquitous language as time goes on and while consistency is of course an important thing in any code base it’s not the only thing.

When do we decide that actually gradually moving to a better approach is worth the temporary pain that having this inconsistency will cause?

Be Sociable, Share!

Written by Mark Needham

May 5th, 2010 at 10:34 pm

Posted in Coding,Incremental Refactoring

Tagged with

  • I am a bit puzzled by the argument that it’s better to keep everything in a consistent, unsatisfactory state, rather than gradually improve things and having to live with only part of your code in a better state.
    Sure, you don’t want everyone to change style all the time in the code and end up with a big heterogeneous pile of code, but if you know you are going to go for it at some point, why wait? Otherwise you will keep adding code following a standard you don’t like, increasing future rework, and increasing the barrier to change even more.

  • @Mathias – I generally agree with that and that’s the argument that I’ve been making.

    I’m not sure if it applies so much in this case because it’s a very short project (7 weeks with 2 weeks left) and maybe we wouldn’t actually get around to changing all the names in that time anyway.

    Of course I’ve been in situations where that has been used as a justification for not making changes and then the project goes on for another 6 months and you really wish you did make the change earlier because it’s much more difficult to do so now!

  • Pingback: Tweets that mention Consistency in the code base and incremental refactoring at Mark Needham -- Topsy.com()

  • Jen

    When we started to evolve our codebase we had exactly the same dilemma – with design approach more so than naming. If we figured out a better way to do something for feature number 2 compared to feature number 1 did we go back and change feature number 1? What if we were on feature numbers 10!

    Figured that the best way is to accept that in an evolving design you are going to have code that doesn’t quite live up to your current ideals. If all your devs have a good idea of the current ‘ideal design’ then design can be applied when you revisit the older code to add/change features. You have to rely on communication, awareness of evolving code and good test coverage. But how are those bad things…

  • Pingback: The Refactoring Dilemma at Mark Needham()

  • Pingback: The Refactoring Dilemma | ASP.NETer()