Refactoring

An interesting situation came up at work recently. I was leading a team that was reviewing an application that was developed about 18 months ago. There were some concerns around performance and scalability. The real question was, did this program need to be re-factored? How do you decide if/when it's time for refactoring?

One of the principles behind the Manifesto for Agile Software Development is Simplicity:

Simplicity--the art of maximizing the amount of work not done--is essential

In other words, keep it simple unless there's a current requirement to make it more complex. Don't try to design for some possible future requirement, design for what you know today...for what features are in the current iteration or release.

I've had architects that have struggled with this idea. They would argue that you need to come up with a comprehensive design up front. However, if the requirements aren't known completely (and when are they at the start of a project?) doing a full design will be challenging. I've seen organizations get caught up in analysis paralysis and have trouble getting anything built.

The key is to plan to the appropriate level of detail. At the beginning of a project there are a lot of unknowns, so a detailed design isn't practical. Focus on a design to get you through the first iteration, or maybe the first few iterations that make up a release. Know when you need to refactor.

What can change to require code to need refactoring. I can think of a couple situations;

• Change in requirements - Everything changes. As business needs change and evolve, the programs to support that business need to change as well.
• Change in technology - What technology are you using today that you weren't a year or two ago? Look at how popular devices like tables and smart phones have changed the the way people work and interact.

So what does this mean? The need for refactoring will always be there. I often advice clients that it's better to get a first release of an application to production as quick as possible, even if it's not perfect. You will start receiving some business benefits and it will give you better ideas on how to improve it.

Agile2011 - Final Summary

Agile2011 is over. The last couple days went so fast, I didn't even have a chance to update my blog until now.  Over the last two days I spent a little time on the topic of design. I'll admit it's a topic I don't spend much time on, but I should.

On Wednesday I listed to a discussion on the topic by Mary Poppendieck. Her discussion was based on the  book The Design of Design by Fred Brooks. The design is basically broken into 3 steps;

1. Understand the problem
2. Design the solution
3. Implement the design

A small team is better than an individual for design and the process is iterative across the three steps. Good design is like Wayne Gretzky playing hockey, he skates to where the puck will be. 

The second design topic I heard was Lean UX by Jeff Gothelf. There's a great article that covers his discussion here, so head over to read it. 

One of the themes I picked up on during the conference was the idea of building value. Design plays into this, designing a good solution. A couple speakers talked about how if we get to focused on delivering the user stories, we can loose track of what the real value we are trying to bring. 

Personally, I've seen this with some of my clients. Even though we're using agile, there is still to much focus on competing the stories in the backlog without much thought about what value those stories bring to the business. It's not a question of getting all the stories completed, it's delivering a product that has real business value.