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.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Process. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • jdn

    I think this is very well stated.


  • Thanks, this was quite timely. We’re facing a similar situation right now, and we’re slowly but surely loosening up those control gates.

    How do you handle after the deadline passes though? Do you push for a refactoring iteration or two? Work it in (via padding) to future iterations? How do you communicate the need to take a feature breather to go back and fix things up for a large and long lived project?

  • @Darrell Mozingo, I like the concept of a “feature breather”. It’s hard to convince higher ups that it needs doing because they can’t perceive the benefits… nor can they ever because the benefits are purely for the developer. The developer benefits need to be translated into some sort of business value which is the one area that drives me nuts.

  • Jeff Certain

    @Scott Muc,

    Depends on your management team. I’m fortunate enough to work for a company that has a product that has been around for a very long time. Management has seen first-hand how big a time sink maintaining a complex code base can be. It makes it fairly easy to make the argument for allowing developers time to refactor and reduce technical debt.

  • @Darrell

    After a release, it’s common to have a post-mortem to talk and analyze how things went down. This is in addition to our normal retrospectives and other feedback.

  • I think you’re right, but there’s a problem here that needs to be fixed, and the problem is that people are expecting too much to get done in the fixed amount of time. I know that we can’t always avoid this situation, but I’m trying to find ways to set realistic expectations up front so that you’re more likely to avoid these situations.