In an ideal world, teams are be highly disciplined with XP practices, and refactoring is part of the Definition of Done for each backlog item; refactoring does not need to be planned separately in the backlog. In the real world, teams may inherit code with a lot of technical debt, or they may have (shame on them!) not been disciplined about refactoring. If your team has enough technical debt to require a significant refactoring effort, how to do you write a good backlog item for refactoring? Does the concept of “user story” even work for refactoring efforts?

First, let’s agree on the definition of refactoring. I like Martin Fowler’s definition:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

I would go further to add that the goal of refactoring is to improve the internal design of code so it is more readable, maintainable, elegant, and simple; in short, so it is easier to change. Refactoring is not a smokescreen for fixing a bunch of bugs. It is not any effort to change functionality. While it may result in performance enhancements, that is not the primary goal: the performance of a system is form of external behavior.

Before starting a big refactoring effort, be sure to ask question #1: When is the right time to undertake a major refactoring effort to pay down technical debt?

Should you embark on a big refactoring effort at the end of a project, before a production release? This could be risky without a very comprehensive set of automated tests. How could you recover if the refactoring causes more harm than good? Would you be better off starting the next release with the refactoring effort?  Note: I credit my colleague Aidan Ridley with identifying this important first question.

Here are some guidelines for preparing backlog items for refactoring.

1. Keep refactoring tasks small (the “S” in INVEST). Identify a single small component or even a single class as the scope of a refactoring item.
2. Use metrics as indicators for refactoring targets. Measure code complexity, coupling & cohesion to identify good candidates for refactoring.
3. Prioritize refactoring backlog items based on the value-t0-cost ratio. The value of a particular refactoring item may be known subjectively to the team, or may be indicated by metrics.
4. Define an adequate unit testing standard before starting. Write all the unit tests required to meet the standard before doing the refactoring, and use them to validate component functionality after refactoring.
5. Identify the components and functionality that may be impacted by the refactoring, and create a test plan accordingly.
6. Create automated system-level tests (smoke tests, integration tests) in order to validate whole-system functionality, particularly for areas identified in the previous step.
7. Identify any open defects that may be fixed by a refactoring. Coordinate with the team on any defect-fixing efforts that might overlap with the refactoring effort.
8. Identify any dependencies between backlog items – refactoring or otherwise. Can you find ways to break those dependencies, such as changing the scope of an item, or creating interfaces between components to isolate work in different areas?
9. Do you need help convincing the Product Owner to prioritize the refactoring effort? Try to quantify the value of the refactoring. How much would the team’s velocity increase as a result of refactoring? What reduction in defects would you expect?

I must give credit to some of my colleagues for helping with some of the ideas in this post.

A tip of the hat to Paul Rayner for recommending SourceMonitor for .NET code quality metrics. I gave this freeware tool a spin today on a C# project I’m working on for a large client, and was very happy. It’s easy to use and within a few minutes I had it installed and ran the analysis on the whole project, gathering these metrics for the whole solution, and for each C# file within the solution:

• number of statements
• methods per class
• calls per method
• statements per method
• average and maximum complexity
• average and maximum block depth (number of levels of indentation/curly braces)

This is a great tool to quickly find potential problem spots within the solution, so you can identify the components that would likely benefit the most from some refactoring and additional testing.

I’ve been using a PPTP VPN connection from my Windows Vista box for a while, and suddenly it just stopped connecting, and throwing error code 800. After many hours of banging my head against the wall and googling for a solution, I finally found it at this link. It turns out to be related to Microsoft Virtual PC 2007.

“If you have installed Virtual PC 2007 on your machine, it can happen that some windows update (I would really like to know which one) destroy some kind of mapping between VPN connection and WAN Miniport driver.”

To fix it you need to uninstall “Virtual Machine Network Services” on your physical network adaptor properties.

Arghhhh.

I spent some time today getting familiar with Selenium, an open-source web app test tool. Along with the Selenium IDE, which runs as a Firefox plug-in, it passed the 10-minute test with flying colors. It looks promising, and soon I plan to put it through a more rigorous test to see how well it handles javascript and DHTML.

I’m the Scrum Master (team leader) for a team of 5 developers working on a complex enterprise application at StorePerform Technologies. I haven’t worked very closely with most of the team members prior to this project, but most of them worked on the same project for a long time. I started the project hoping that I could serve both as the team leader (following the Scrum principle of servant leadership) and a part-time developer. I reluctantly came to the realization that it doesn’t work, at least not with a new team which is still in the Forming & Storming stage. As my colleague Yuri Gadow helped me understand, the likely result is that I will be a bad leader and a bad developer – the worst of both worlds.

The team has taken the concept of self-organizing teams to an extreme, and they resent any suggestions from the Scrum master. My goal is to gain more trust and respect from the developers so they’ll be more open to my suggestions. My solution was to switch roles for a few sprints (iterations) – I will be a full-time developer, and hand over the Scrum Master duties to Yuri. I believe this approach has several benefits:

• I can focus on doing one thing well: writing code
• I can keep my development skills honed
• As an equal peer to the other team members, they’ll (hopefully) learn to respect my technical skills and experience
• I have the opportunity to “feel their pain” first-hand
• The team (including me) will experience a different leadership style from Yuri

After nearly 4 weeks in the trenches, I think it’s working well. Unfortunately, StorePerform cut the experiment short when they laid offthe entire US development team and outsourced it to India.