fuzzylizard

For the last day and a half I have been wandering around in the dark trying to solve bugs with the project that I am working on. The project lost its guide; we lost the last original developer (his wife had a baby, congrats Igor). The result is that we no longer have anyone who understands the design, the implementation and the domain.

It is amazing how this changes things. Where before we could show him a bug and within minutes he could guide us to the answer, we now fumble around trying to understand the code and what it should and should not be doing.

I think the biggest thing this has shown is the huge holes in our understanding, of my understanding, of what the application actually does. The mood of our stand-ups have changed as well. Now there is uncertainty and doubt when it comes to fixing bugs. The confidence we had last week is gone.

A few weeks ago, while at the Chicago office, I was a part of discussion in which someone brought up the idea that Story Cards should not be closed until they have passed their acceptance criteria in a production environment. Mix this in with something Fred George posted the other day about dealing with bugs.

if a bug blocks a story, then the clock is running on that story until it is fixed and moves forward. Developers on a Lean-oriented team will attack bugs rather then work on development of new stories. The net results is few bugs live for more than a day.

These two things together ensure that a project has very few bugs. It ensures that conversations that need to take place due to bugs are done with the client and the developers who implemented the story card.

There is an implication in closing bugs in production though and that is that you need to have a production environment in which to close them. Far to many projects leave the production environment till last. The software is finished and everyone is waiting around for it to be deployed to production. Since production is the first fully integrated environment in which the software is used, there are a tonne of bugs found and the official release is delayed. But the bugs are harder, and more expensive to fix, because the developers who implemented those features are now long gone.

Granted, why should a company buy hardware and software licenses now for an application that is not scheduled to be released for several years. But compared to the amount being paid to develop the application, the cost of the hardware and software licenses really is trivial; it represents a very small percent of the total cost of the project. The problem is that it can be the most visible cost.

Closing a story card in production also means that the story card has been thoroughly tested in that environment. This should mean that real users and have actually used the application, for real, before they close cards. This means that the business rules are correct and the developers can move on to other areas of the application. This means no bugs.

And no bugs is a very cool idea.