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.