Quality against a deadline

Parkinson’s Law states:

Work expands so as to fill the time available for its completion.

With one week iterations on an XP team, we really don’t have that problem.  On previous teams, with lengthy six month waterfall cycles, work might get completed in a month or less, but we had to do something until launch night.  Re-work our builds, adding coverage, refactoring, improving automation, refactoring, refactoring, refactoring.

But with such a short cycle time, there’s not much time to fill.  Up against a hard deadline though, I’ve found a corollary:

Quality decreases as a deadline looms

As a hard deadline looms, it doesn’t seem to matter what our practices are.  Every team I’ve ever worked on has cut corners when up against a hard, important deadline.  At some point, the value of our quality-control measures, whether it’s CI, gated builds, unit testing, or avoidance of hacks, all seem to whither away when a deadline that we can’t miss comes up.

And I’m fine with this.

At some point, we have to realize that there is value in delivery, and a goal beyond our own measures for success.  We as developers know what it takes to create maintainable software, but maintainability is merely a goal that must be considered along with all the other business goals at hand.  Now, in my book, maintainability is a goal of the utmost importance for many projects, especially projects of any significant size or duration.

But what if we’re in a situation where marketing materials, advertisements, and printed stock all point to a release date?  These types of materials must be set up months in advance, much larger than our iteration size.  So what are we to do if the hard release date comes calling, and we’re not quite finished?

Many hard decisions are to be made at this time, but if we can see the light at the end of the tunnel (a VERY important if), I see it as our duty to sacrifice quality in the interest of a deadline.

Frequent deadlines

I’ve also worked at places where management abused this duty, and imposed frequent hard deadlines upon us in order to prod us into sacrificing quality and our free time more and more often.  In these cases, it’s also our duty to push back in favor of a larger, sustainable goal.

It’s too often that we get caught up in our own myopia – not seeing the larger goal at hand.  Part of this problem is management, in not defining and translating larger goals into tangible team goals, but it’s just as much a developer’s fault, wanting to be master of their own local domain.

As much as it pains me to do so, I still have to recognize when it’s time to just get the product out the door, and skip the quality control at the moment.  As long as I effectively communicate these risks to the decision makers, I’ll sleep well at night.  Because when you put quality up against a big deadline, the deadline always wins.