Bug hunt on the refactoring project

The refactoring project rolls on. Mostly it’s been more of the same so I haven’t bothered boring my reader with the details. This week we had an interesting bug to fix. The bug had appeared in a much earlier version, way back in July, but it had only been reported by one user and we could never duplicate the problem. This week we managed to duplicate it, and then we needed to work out what it was and when it was added to the source…

Back to the refactoring project

I’ve spent the last couple of days back with The Refactoring Project. They’ve done well in my absence. They managed 3 releases; all correctly tagged and repeatable. They started some refactoring of their own and, at first glance, it looks like they’ve taken on board lots of the suggestions I’ve been making over the last months. They’ve fixed a couple of new bugs in the FX code and whilst doing so found that a) the bugs were easy to locate, b) they were easy to fix with very localised changes, and c) the new code was much easier to work with!

You'll tick when I say so and not before!

Today we wrote some complicated FX business logic tests. Things like making sure that the FX library can calculate a EURUSDCAD 1M rate - it can; or a USDCAD ON rate - it can’t and nobody had spotted the fact that it was out because it’s way down in the 0.00001’s of the rate. It has taken us around a week to get here. The initial code was a tightly coupled mess.

The first FX test

On Friday we got to the point where the FX buiness logic code was suitably decoupled from the display logic that we could write our first test for the business logic. In the words of Homer Simpson, “Woo hoo!”. Test one was a simple one; can we construct the FX ’live point’ object. After adding a few interfaces and mocking up a service provider or two we could. The object uses two-stage construction; not ideal, but the code doesn’t use exceptions yet.

FX refactoring

Bleugh! You are lost in a maze of crapy code, all alike (and much of it copy and pasted!). The last few days have been deep in the heart of darkness. Gently teasing the business logic and the display logic of the FX code apart so that we might one day be able to write tests for the business logic. We’re nearly there but it’s been a long job. Much longer than any of the other refactorings that we’ve done.

It's important who's driving

I’m a firm believer that software rots unless you’re very careful; and like apples, once one piece starts to go bad the rest quickly follows. The Pragmatic Programmers talk about Software Entropy and The Broken Window Theory and, unfortunately, this week the refactoring project showed how true this is… We’ve spent several weeks working on cleaning up this project, but there’s a lot of code and it’s all in a bit of a state.

Developer buy in

The refactoring project rolls on and the code gets better. This week saw a marked change in attitute from some of the developers on the team… I was originally brought into this project because the lead developer was leaving and other developers within the team were unhappy with taking over the project as they were scared of the state that the code was in. Management accepted the need for change and welcomed the incremental improvements that my original report on the project proposed.

We came. We saw. We did a little testing.

Another week another release. Well, almost. The plan was to release today. The plan ignored the fact that most of the team are at a wedding this weekend and nobody was around today and nobody’s around on Monday… The latest release included some new functionality and a lot of refactoring. Given the amount of code that had been ’touched’ I recommended a longer test phase than we usually planned, i.e. more than 1 day.

One step closer to sanity

Now that the refactoring project has tests it’s worth having a daily build so that it’s easy to spot if someone checks something in that breaks a test. I spent 30 mins or so first thing this morning writing a script that pulls all the source from CVS and builds the test harnesses in debug and release mode and runs them. This now runs daily on my machine. Most of the day was spent moving as many classes as possible into the library.

Refactoring project: Joel Test, reprise

Last week we were a 5.5, now we’re an 8. Not bad progress, but there’s still a long way to go until the project can get a ‘SaneMark’… We can now do a build in one step. We had several point releases last week and we can now do them with a script which will pull all correct source files out of CVS, build them and create the suff that we need to push out to the web server.