English has this wonderful term called "Senioritis" where US high school seniors often give up on hard school work in the final days, weeks or months before graduation. They figure they can coast to the end and do just fine. There is an unspoken wisdom to the pressure valve opening, especially at the realization that childhood is supposed to be over and now you must go off and live your life. Adults know that the real transition is when you leave student academia for work and that transition may not happen for several years.

Software projects can go through a similar senioritis. It happens near the end, after some major milestone has passed and things go from frantic to calm, like the sea after a storm passes. There is a lot of churn and the flaws and damage are laid out for all to see, but the frantic pace and long hours are mostly over. I look at these senioritis times with a sense of cautious optimism.

I'm cautious because some people become sloppy and stop doing the things they have been doing for months. My favorite change is the sudden disappearance of the steps to reproduce a bug. I may get great bug reports with detailed steps to reproduce the error and the suddenly I get bugs from the same people that say "Dialog doesn't work" and I go into that dialog and find it does work. I try two or three more things but the error doesn't manifest itself. The normal thing is for the developer to mark the bug as not reproducible and wait for QA to reopen it after adding some new step or some missing clue.

I'm a stickler for following procedure and protocol. It can drive some people bonkers that I want nightly builds, comments with commits to source control, bug numbers with commits to source control, steps to reproduce bugs and the resolution comments for that bug to be something more than "fixed" unless it was remarkably easy like renaming a field's label. It isn't unusual for me to visit or email a staffer asking them to stick with the protocols we have been living with.

I know, someone is rolling his eyes saying that I'm just a procedure pushing dumbass. That I'm enforcing procedure rather than facilitating development. Some times the comments in a bug are enough to tell the developer how to fix a bug with no need to have steps to reproduce. Those people are correct up to a point. Common sense does kick in because we don't need to have steps to reproduce an error when we are talking about changing the label on a field though the change may be tracked in the bug tracking system. The point is that we follow procedure in the big and little things alike so that everything works consistently.

Consistency and reproducing consistency are valuable for limiting miscommunication. Skipping protocol means that details are lost and those details may need to be found again. We have to trudge through the base work to get back to the original point. Skip the daily builds and you don't know when a major build change occurred that breaks the product and prevents the next release. Skip documenting the steps to reproduce a bug and other people on the team can't figure out what is going on, or worse: a developer reproduces what looks like the bug but he really fixes an entirely different bug that exhibits an identical looking error.

A project experiencing senioritis sees the procedures breakdown that brought you so close to the finishing line. As details are lost, so are the hours before the project is done. The pressure comes back to the old frantic pace, rising just like the waves on the sea and pretty soon you find yourself in a storm in the hours before releasing the project. The moral of the story is to stick to procedure, be consistent throughout the project and don't let normal everyday processes slip until the project is done and shipped.

Seth Godin wrote Dumbing Down and it reminded me of dumbing down code and dumb bugs. The latter is what interests me for the moment.

My first and second jobs were tech support. I graduated from college just as DEC, Wang and Data General were winding down and preparing to fade away. The result was a saturated job market and I was thankful to get the gigs. Those two jobs taught me a lot about software development and how bugs really affect customers.

The worst bugs were those that didn’t add anything to our products beyond the appropriate level of polish. Bugs like spelling and grammar mistakes, minor UI alignment issues, terminology issues, etc. Customers really do call about these kinds of issues and some customers actually get really angry over them. They have a right to be upset too: they spent a fair amount of money and expect things to look and work right.

Dumb bugs are often really easy to find and fix. Sometimes they get missed anyway or they get a really low priority in the bug database and are prioritized right out of the development cycle. Missing these things is sometimes fine, everyone makes mistakes and some of us can’t spell if it weren’t for spellcheckers. However, they should get fixed quickly once they are entered into the bug database.

It usually takes only 2 or 3 minutes to fix a spelling or nomenclature mistake. Just a couple of dollars to update the code, usually a resource or configuration file, and close out the bug. Its cheap to fix.

Have a customer call and complain about these bugs takes up tech support time and customer time. Tech support time can be cheap unless you have a huge product and receive hundreds of calls a day. Annoyed customer time is a different story. They may get trapped in a long call queue and become progressively more annoyed as time goes on. They were annoyed enough to call in the first place and then they got more annoyed when they had to wait. A customer is not going to drop a product because of minor errors. But they will drop a product if they find too many bugs and thats part of customer churn. Now its expensive.

Tech support lines educate customers as well as improve the product. Tech support staff can log a lot of bugs, the good ones are those that detect an edge case problem such as a crash if you pull up three dialogs in a certain order and drop in a URL in one of the fields. That’s a good bug to fix. Other calls will be about security flaws or other bugs that really improve the product. These are really valuable times for tech support to be there.

Customers will always find bugs. Software is too complex for them not to. What kind of bugs do you want them to call about?