Moving from cowboy coding to agile development

Thursday, November 24, 2005

First Randori Session in Helsinki

I participated the first randori coding dojo session in Helsinki today. In short: it was fun.

It was really great to see other people in action, making decisions using TDD with people they had never met before. The discussion was really interesting. This was also one of the most controversial things about the randori session - I think the audience was suggesting a bit too much on the implementation side, but on the other hand, that way all of us perhaps got to hear more views on the problems that we would have otherwise. So, it's hard to say whether the future sessions need to be more disciplined or not. Either way, I'm definitely going to join them.

Thanks again to all the guilty parties (Markus, Pekka, Lasse)!

Saturday, November 19, 2005

Being Agile on Project Level

One of the reasons I started this blog was to keep track of the steps I'm taking while moving from cowboy coding to agile development. I figured that people who are considering the same transition later might be able to find some pointers here.

Now, to fulfill the latter purpose, instead of writing something ignorant about using XP on project scale, I'll just let the more competent writers take the stage.

First, a very good newsgroup message by Robert C. Martin (in Second, a blog post by James Grenning (on

I have nothing to add.

Friday, November 11, 2005

The World Doesn't Want Me to Code

I've been busy this week. It culminated today, when I spent the whole "working" day doing another school assignment. I slept only a couple of hours last night, trying to finish the task in time. I couldn't make it, and when I realized I would miss the deadline, I laid back a bit. Leaving my laptop on standby I spent two hours elsewhere. When I came back, the machine had crashed and failed to reboot.

So, there I was, staring at a laptop with a (probably) broken hard drive. The code I was working on was (and is) probably gone for good. After the first hour (or two, or three) I am finally starting to realize this isn't the end of the World... just the end of the coding spree I really would have needed.

Wednesday, November 09, 2005

Note to self: Learn to make "big" decisions faster

I had a nasty problem at work. I was asked to add some functionality to old code that took the contents of a set of data and transferred them to another data set, changing the data to different form according to given criteria. What I was supposed to do was to include some previously excluded data in the transfer. It doesn't sound that difficult, but when the function that does the actual transfer has 7-10 different branches doing different things (according to the given transformation criteria) and nobody seems to have any idea how it does what it eventually does, the task becomes rather challenging.

My big mistake was to try to include my own additional code to the method (actually, the language only has functions, but it's easier to understand this using Java terms), so that the source data set could be read only once. I ended up banging my head against a wall for 5-6 days trying to understand how the old code works. This Frankenstein of a code was about 250-350 lines of code, with loads of if-clauses, loops and boolean flags. I tried debugging and running the transfer with a couple of outputs to track down the general idea of the existing code. I guess I made some progress, but just couldn't make the bloody thing work as a whole.

Finally I decided it's better to leave the monster in its cage and work around the problem in another way. So I added the new parts of the transfer only after the existing part had already been executed. The fix was ready to be tested in about 15 minutes.

You might be able to imagine how stupid I felt. This solution forces the program to go through the source data set twice, but since it's always pretty small and there are no database queries involved, the decrease in efficiency is probably too small for a human eye to even notice. The only thing with which I can defend my stubbornness to include the new functionality inside the existing code, is the logic that these things are closely related/connected and should be done together. I still think such logic has its place in designing such additions to existing functionality. However, if the options are to spend more than a week fighting a losing battle or doing the desired addition in less than an hour, it's probably justifiable to choose the latter option.