I’ve spent the morning doing test driven development, properly; writing tests first and everything. It works, it’s faster and it’s addictive. The current work item for the online game is to take the existing game play and adjust it to include a few of the more complex special cases. This alters the game play a little, it alters who goes first, etc. It took a while for me to elicit enough detail to fully understand the requirements, but now I have it.

Agile Software Development - Principles, Patterns, and Practices by Robert C. Martin This book is physically heavier than most of the books I’ve been reading lately but I’m still carrying it to work even though I only get around 5 mins reading done on the tube during the journey. It’s a beautiful book; the typeface and illustractions are stunning, the paper feels rich, the cover is cool and colourful. The content is pretty good too.

A while back Carson asked me how I managed to keep track of all the projects that I was working on; I said that I had practiced being productive over short time periods, tried to stay focused on one thing at a time and not to switch projects too quickly. There’s more to it than that though as I found out recently… Recently I’ve been busy. Too busy. I managed to maintain the pace for a couple of weeks and then ended up wasting a couple of days thrashing as I needed a bigger time slice than I had available and I kept trying to use the time I had to do a task that required more time and that had to be done in one go… Note to self; try and spot that next time and use the small time slots for more appropriate work.

The free source code integration project has its first code drop and then its second code drop… Almost complete. The integration has gone pretty well. The server code now has a neat little facade that allows it to impersonate the MFC server code that the client wants to replace.

The online game approaches completion but recently the requirements were lacking and we couldn’t see the way forward. We’re finishing the game play and getting to the complicated special cases - I’m hoping that they won’t be complicated or special once I understand them more… The original story that explained the latest piece of work was lacking when we analysed it closely; we fleshed it out and now I think we understand it enough to quote for it and code it.

We’ve been moving pretty quickly on the refactoring project. We had got to the point where we were doing at least two releases a week. Generally we would include user requested fixes in the first release and refactored code in the second. It started to become a little hectic. Last week we decided to slow things down a little so that we could regroup… One aspect of the project is a currency exchange rate display.

So there are 10 guys on a stag weekend in Amsterdam. Much drinking. Lots of foolish games with very fluid rules and fines for people who did not comply. Many fines were collected. At some point during the drinking games on the first evening, number 28 became significant. It was decided that the money from the fines would go on 28 when we visited the casino the following night… Fast forward to the bar just before the casino and the collection of fines had reached around 135 euros and we started to lose our bottle.

Brian Foote and Joseph Yoder writing about software architecture (or the lack of it). Thanks to Bryan Boreham for the link.

A couple of days ago I posted some untestable code. I’ve had a couple of emails saying that people couldn’t see why the code was untestable. Here’s why, and here’s how to fix it. The code shown manages a list of listeners who are interested in being notified when the system date changes. It’s externally driven by calling CheckForChange(), this could be called in response to a timer event or from a polling thread, or whatever.

Finally finished reading Waltzing with Bears: Managing Risk on Software Projects and it was well worth the read. Waltzing with Bears is a book about managing project risk. It’s a slim volume, but packed with useful information. As usual, DeMarco and Lister present the topic in an approachable and readable way. The text is full of anecdotes that flesh out the theories with practical examples. In a nut shell; most project managers on software projects fail to adequately manage risk.