The days before Day Zero

About a month ago my boss told me about a nice and shiny project that is quite crucial for his company and that is about to enter it's final stage. Of course I can't mention a thing about the subject of the project, nor the people involved, but that's quite irrelevant to the story I'd like to blog about, I guess.

The next thing I was told, as one might suspect, was that probably this project isn't going as well as it is supposed to, and more importantly we don't know that for sure. One of the first things that went through my mind was: what is the development method they use, do they use any automated test and stuff. Of course the answer was no. "No" as in "no they don't use any method at all", "no they don't have any automated tests of any sort", and more no's followed.

At the moment I was deeply buried consulting another project at another company. This subject deserves it's own blog entry possibly but to cut it short, that project also wasn't going as well as it should, and even could go (though they do have the potential), but after half a year of struggle mainly with the management of that company I had to give up, as I saw no progress in software engineering practices at all. I can tell people things once, twice, three times, but for the love of God not a dozen, and certainly not so basic things that they just happily choose to ignore. They'd certainly would have to pay me more to compensate for the irritation they cause, and they should at least pretend they listen to what I say. They chose otherwise, well good luck then, a typical shiny Death March, with heads high, proud look and striking bravery. I'll send them a post card, or two.

Anyway right now I'm still engaged in that project for half of my time, but my heart and the rest of my time I dedicate to the new one. Those proportions are very likely to change in the near future, as I find the new project much more responsive to treatment than the old one. Id est the people are willing to cooperate, and they are ready to admit the reality surrounding them, weird as it may sound, but not many are ready to do that.

The primary thing that the main stakeholder wished to have are a certain level of unit test coverage, so that was the first thing that I was told that he wishes to be done. Generally I agreed with that, who wouldn't, we love to have unit tests all around. But my main concern was: is the absence of unit tests the only problem of the project. Well as one might expect, when things unfolded, more monsters came out... Anyway my boss sent me there to secure the well being of the project, and that's what I'm going to write here about.

I've spent around 6 days so far with the team over the last month. The first day I had a presentation about Test-Driven Development (or Test-First Development as nowadays is preferred to say), combined that with a little show and tell and a general discussion about ways of software development. The subject was nice and I needed a solid starting point for a discussion to get to know the team, and it's problems. The response was very good, the team liked the approach very much and they were quite enthusiastic about working that way. I ended the session by leaving them to read the TDD by Example by Kent Beck, and a suggestion to try to use this approach themselves.

I came back after a 2 week holiday and collected feedback. Never mind that for now, there were some problems but at least they strive to write new code the new way.

I then begun observing the project structure itself, I noticed over 40 modules in the SVN repository, but there were no automation scripts that would put all of those modules together. Most of the job was done by hand, some through Eclipse's builders. So the first technical thing I decided to do was to install a few collaboration environments. So I installed JSPWiki for sharing knowledge and maintaining useful data, Luntbuild for build automation, and XPlanner anticipating the further need for it for planning and sharing that with remote teams and stakeholders. Then I begun preparing scripts for Luntbuild to be able to build the system, outside of the development environment, on a separate test machine. Having 40 projects, I soon realized that I'm doing too much copy-paste operations on scripts, so I decided to move to Maven2. I never really used it before so it took me some time to figure out how to customize all the various directories and other stuff that defaults to something different from what the project has. I didn't get a chance to finish the task just yet, as in the next days other things caught my attention.

The leading programmer has a habit of drawing the project structure on a whiteboard and assigning percents it's elements meaning how much is done. What struck me was that all of this came from his head. The features to be implemented weren't written down anywhere. The general understanding of what to do of course was signed with the contract, but that was just as general as it sounds. There was some analysis document but it was vague and incomplete. Moreover there is not a single place to hold, what is done, how do we estimate what has to be done, and when approximately will we finish.

We have a date of course, the 28 of July 2006, but no one really knows what will be done by that time. The customer is sure we'll do it all (whatever *it* means). The managers believe that too. The programmers on the contrary are quite sure we wont be able to do it all in time, and we'll have to mask it somehow.

I don't like situations like that, or to be more specific I hate situations like that one. I like facts, there's no shame nor guilt in telling the truth as soon as possible. There is however shame in covering the truth or even just not being straight forward with it, I strive not to do that.

Well given that, the first thing I decided to do was to force an stocktaking of what we have and what we need, a Planning Game to estimate the size of what we need to develop, and a change in the development flow to have nice observable cycles of development, say weekly Iterations. So over the next few days I talked to people. I talked to one of the programmers there who is my colleague from my company, asked him what does he think about it. I talked to my boss. I talked the manager of that project. After I received green lights everywhere in the command chain, we sat down to work.