A new assignment

My ex-project and I had been together for ten months. We had our fair share ups and downs, particularly in the early days, but over the last few months we had settled into a nice routine. It wasn’t particularly exciting any more but at least it was predictable.

And then yesterday I was asked to lead a troubled project. It’s only six months old and already has quite a few warts, and it limped across the line into UAT last week. My first instinct was to cower in the corner in the fetal position but I resisted that temptation and quietly accepted the role.

The challenge with assignments like this is to avoid making drastic changes straight away. Most products are only a few tweaks away from being great so the approach I’m going to take is to make a few small adjustments and re- evaluate: build, measure, learn. Repeat. The key will be to get a deep understanding of the codebase and the business problem its trying to solve before making too many changes.

I have heard the “R” word being bandied around but I refuse to even consider a re-write. If there are significant changes required we can refactor towards the new goal. Joel Spolsky puts a re-write at number one in his list of Things you should never do, and I agree one hundred percent.

It’s going to be an interesting couple of months, but hopefully I can get the project back on track and start shipping better versions every two weeks.