Blog of Keith Craig, containing my thoughts, comments and questions. RSS Feed


Continuous Improvement

SCRUM is an agile software development methodology, and one of its basic values is continuous improvement—making small changes often so that they add up to big improvements over time. SCRUM facilitates continuous improvement by having a retrospective at the end of each sprint where the team discusses what they liked and didn't like about the sprint. They then prioritize the things they didn't like in order of what they most want to change in the future, brainstorm improvements for the top few, and then implement them.

This is a simple but powerful concept. If you can make some small but lasting improvements each sprint, they really add up over time.

I was struck by the power of continuous improvement during a recent sprint when I made a fairly trivial but lasting improvement. We use a custom code-generation tool, and we regenerate code regularly to accommodate database schema changes. After several refactorings, the tool created all the classes together in a single file, with a generated comment for each class. For technical reasons we needed to recompile the tool each time we regenerated, so the version number changed each time. This led to the inability to easily diff the changes made after regenerating, because we had over a hundred generated classes (and therefore over a hundred version numbers) that changed each time, making the actual code changes very time consuming and annoying to find:

Interestingly, some of the team is running Vista and some are running XP, and as shown above, the version numbers for the runtime are slightly different.

Anyway, this felt like driving with a blindfold—I just regenerated thousands of lines of code with a click of the mouse, but I couldn't go through and easily view the changes. Instead, unless I was willing to click through over a hundred differences, I had to hope that everything just worked, and that there wasn't anything unexpected happening that I was then checking in.

In the spirit of continuous improvement, I decided to change this. It took about a half an hour; I explicitly set the code generator version number to 1.0.0.0—this way it only changes when we want it to. I ended up using a surgical regex to remove the .NET runtime version line, as it doesn't add much value for us. Nothing fancy, just get rid of version numbers that change.

The result: by spending half an hour, the entire team is now able to see the specific changes each time they regenerate code. Doing something like this to improve things slightly, but in a lasting way, is very powerful—and it feels great to resolve a small but annoying issue!

 

 
Posted by Keith Craig | 0 Comments | Trackback Url | Bookmark with:        
Tags:

Links to this Post

Comments

Name:
URL:
Email:
Comments:

CAPTCHA Image Validation