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.
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.
The refactoring project reached an exciting new stage on Friday. We were finally able to refactor some code to the point where several classes could be extracted from the application project and built in a library that the application then linked to. This required that we reduce the coupling of the classes and increase the cohesion. Once these classes were extracted we were able to set up a test harness project and write our first test case!
I come from a family of pessimists, but I think I got off lightly… I’m just slightly on the ‘doom and gloom’ side of centre. I expect this probably accounts for my attitude to risk. I assume bad things will happen. I want to know what the worst case scenario is. I ask difficult questions in meetings. Just be thankful that you don’t end up in a meeting room discussing your project with my sister…
I think best when I can scribble. When designing software I always draw boxes and lines. These diagrams give me an anchor to come back to if I get distracted. They get binned once they’re no longer needed. Pen and paper is the only way I do this, Visio is great for after the fact diagrams, but it’s too slow to catch the thought process.
To be able to keep up with my thinking I need a pen that scribbles well.
I’m currently developing an online game for a client using The Server Framework. I didn’t realise that it was an online game when they originally contracted me. It’s become a useful example of emergent requirements. Each time I think the project is complete they come back to me and say “and now we want you to quote for doing X”…
Almost a year ago I published a series of articles on a piece of code that allows you to write TCP/IP servers on Windows machines.
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.
One of the problems with the code base that we’re refactoring is that it’s full of dead code. This week we dealt with it…
Throughout the system there were swathes of code that were commented out, there was very little in the way of explanation as to why the code was not currently required and when it might be required again. It may have been old code that wasn’t required any more, or was broken or new code that wasn’t finished yet, or was broken.
Bob Cringely has been upsetting some programmers with his comments on refactoring. Initially, he had this to say:
“Cleaning up code” is a terrible thing. Redesigning WORKING code into different WORKING code (also known as refactoring) is terrible. The reason is that once you touch WORKING code, it becomes NON-WORKING code, and the changes you make (once you get it working again) will never be known. It is basically a programmer’s ego trip and nothing else.
Joel Spolsky has a quick test to rate how good your software development process is.
I thought it would be useful to see how the refactoring project scores.
1. Do you use source control?
Yes. The main part of the team has always used CVS for source control and do it properly (tags, branches, all kinds of stuff). This project’s lead developer didn’t believe in source control, but eventually the rest of the team dragged him into the light.
