Developer’s Fatigue and the Art of Not Finishing Strong

One of the worst things a project owner can do is push out a launch date and expect the development team to hang tight. Your crew has busted rocks to hit an ambitious deadline only to be told “we thought you’d be happy to have a bit more time.” Nice. It’s the first in a series of events spiraling the team into an exhaustion I call developer’s fatigue

Developer’s fatigue occurs when the programming team hits their deadline. But no one else does.  Now, they’re chained to their desks servicing an endless number of tweaks, requests, and bugs with no formal expectation of when they’ll be out of the woods.

For all the contempt that programmers have for short timelines, they need ’em. In fact, they should insist on them and require they be held to by their clients too.

A good timeline indicates a point in time when the team expects to be done with a set of tasks and ready to move on to something else. It tells a team how to ration their energy, their workday, their private lives, and so on.

So, what should we persevering souls at the tail-end of the project foodchain do to stave off the disposal of the due dates we’ve honored?

Work for yourself

Don’t work for other companies and stay true to your own commitments. This means, obviously, that you’re not doing work for hire anymore, rather, you’re likely building a product or something along those lines. If your bread and butter is consulting work, this doesn’t apply. Likewise, if you don’t organize yourself and stay on the ball, you’ll get a swallow of your own bitter pills and, worst off, not have a finished product which pays your bills.

Don’t launch. Release. Now, do it again.

There’s a whole lot of money, angst, title promotions, and organization  tied up into one big event, your launch date. With the exception of major multi-channel advertising events though, i.e. the Superbowl, you have more than one opportunity to hit the mark. Thus, you should insist on the ability to release more than one build of a site. It’s healthier that way and promotes prioritization and teamwork. Trying to squeeze out a perfect app in one try doesn’t work, and more importantly, clients fail to prioritize their requests, treating everything with equal importance.

You should insist on the ability to release more than one build of a site. It’s healthier that way and promotes prioritization and teamwork. Trying to squeeze out a perfect app all at once excuses clients from prioritizing and they end up treating all requests with equal importance.

Lift and shift project schedules

Instead of working between start date x and end date y, create a calendar based on the days required to get the work done. So, instead of agreeing to start on January 1 and launch on February 1, insist to the client that you need 30 days to do the job right once full production begins. This way, when the client gets you started late and asks you to deliver early, you can point back to 30 days in your agreement, rather than hard dates your team will have to swallow. As part of your own due diligence to your client, make sure you define what dependencies must be met prior to getting the project into production, i.e, design files, copy, functional specs, and so on. Live by the sword, die by the sword.

Enforce discipline through contracts

If a client insists on a ‘one chance to do it right’ project, then contractually obligate your client to hold their end of the bargain at each crucial milestone. Ensure that your work agreement specifies validity only between start date and end date. And don’t guarantee staffing if that date comes and goes with out a cadence.

Change orders, rush fees, and lift and shift timelines are all administrative controls to keep the broader team aligned.

Stay disciplined as a team

Over the years I’ve observed a tendency for teams to abandon process the closer they get to a launch date. To use the travel metaphor again, it’s like second guessing the itinerary you put together before leaving the house .

When regular fatigue sets in a couple of weeks prior to your launch, make sure everyone continues to use the bug tracker, impose change orders, sketch before implementing, and hold daily calls. This applies to your team and your client.

Fact of (the developer’s) life

You can’t always avoid developer’s fatigue, but you can deal with it. And keep in mind that your team is well-tuned and more disciplined than any other. That’s because you’re carrying projects to the finish line time after time. So, if anyone tries calling you out for not finishing strong, let ’em know you’re happy to discuss it later. Then schedule them via Outlook  for a 2 am call with your dev team when you’re all making up for their lost time.