Wednesday, April 22, 2009

How to adopt Continuous Refactoring?

This is a question that I have been asking myself, as well as received from others, a bunch of times. I am posting it here in the blog since I don’t have a ready-made answer. Please leave some comments on this if you have suggestions.

To clarify the question, let me begin by setting the scene for you;

Let’s say you are introducing Scrum. The team is, as always, a bunch of developers with varying experience, competence, and ages. You have read my blog ;-) as well as other even better sources of Scrum & Agile ideas and opinions, and you understand that the concept of “continuous refactoring” is central. You realize that anything is less likely to succeed if you try to solve everything at once in one single shoot; so it is better to work iteratively and deliver in increments, in order of priority. How do you get this message through to the developers, so that they really adopt it, wholeheartedly, in practice?

Because the problem here, in my experience, is that most people take a lot of pride in their work and “continuous refactoring” is easy to mistake for “rushing things out”. Some people just can’t get used to the idea of not attempting to do it “perfect” or “complete” from the beginning, and thereby find it extremely hard to deliver something that “just works” and is “good enough” for that particular product increment. Obviously, people are different (and so are programmers ;-)), so some will easily adopt this way of thinking, while it will be much harder for others.

How do you do it? It probably has much more to do with psychology and leadership than with Scrum per se, but I still think it is a relevant topic to bring up within the boundaries of this blog.

My suggestion on how to go about this is to educate. Talk about it. Have trainings. I have had lengthy discussions about this topic in the Scrum training sessions that I’ve held, and I can’t say that it has magically solved anything just like that, but I think the key to any change is for people to understand the need for it – and the first step for that is to talk about the problems surrounding BDUF (Big Design Up-Front, which is sort of the opposite of Continuous Refactoring).

Please leave some comments.

6 comments:

  1. I find a different attitude, they make it good enough in the first round and then don't have the guts to change it.

    ReplyDelete
  2. One thing that I think is easily missunderstood about Continuous Refactoring is the fact that it doen't meen that you should write sloppy code. If you work with financial or sensitive information you might say "We have to do it right the first time because we can't afford to have vulnerable code." and see that as a way to avoid Continuos Refactoring. But what Continuos Refactoring means is just that if you need a button that opens a door you don't have to build a blinking button that activates a scanner to scan you biometrics and checks that against a database before opening the door. Unless that is what you are actually building. But if that's the case then you might not have to spend time paiting the door in perleasent color. Do what you need, do it right, but don't OVER do it until that need arises. Then you go back and add that functionality.

    ReplyDelete
  3. Per; yes that is quite an interesting scenario. One has to ask oneself: "Good enough" for what? For what the system calls for at that moment in time, yes. But changes always come... It has to be OK (and even normal and desired) to refactor.

    ReplyDelete
  4. Daniel; Good point. Continuous refactoring doesnt mean its OK to increase technical debt. What exactly that means in practise depends on the context, but it has to be discussed so that everyone is allowed to understand and get a feel for the difference between shortcuts (causing technical debt) and "good enough" (just enough effort to be acceptable). Thanks for your comment(s)!

    ReplyDelete
  5. I do have a question on tracking refactoring efforts. We did some implementation about new functionality and the story have been closed properly. Because of some developer-requirements, the developer wants to refactor parts of the code. We are not sure if it would make sense writing a new user story, because for the user of the product it's not a benefit. Only to developer in regard to code quality and speed of further development. Do you track it as a dedicated story? Who would be the user? The developer?

    ReplyDelete