Artificial Deadlines Are The Devils Work

0 comments suggest edit

Artificial Teeth In my last post, I mentioned that even in high pressure situations, I would take my time and follow certain practices I believe lead to better code, even if it meant taking longer to complete the code.

I took this approach because I felt secure enough in my career that I was not likely to get fired outright. Or at the very least I wouldn’t mind a bit of severance to fund a short vacation. I was confident that my overall time spent on the code, when taking into consideration time to find and fix bugs, was less than others who rushed through the code and spent the majority of their time debugging it.

However, there is another key fact I realized that kept me from rushing headlong into code oblivion. Many deadlines are totally and completely artificial, and I was tired of that bullshit.

“Tell me how you really feel Phil.”

Linus Oh don’t get me started.

An artificial deadline is nothing more than a comfort blanket to satiate a stakeholder’s need to feel in control over a process he or she refuses to understand. See the image on the left, that’s the stakeholder in charge of your project.

Most executives have a pretty solid understanding of corporate accounting. Yes, they trust the CFO to handle the specifics, but they understand the basic principles. This makes sense of course. A CEO who runs a company really ought to understand how the money is flowing in and out of the company.

Unfortunately, this same principle seems to apply less to software development. If a company undertakes a software development project, arguably one of the more expensive engagements a company can take on, it would make sense for the executive in charge to obtain a basic understanding of how real software development occurs.

Barring that, at the very least, trust your CTO or lead tech person, whomever that may be.

When given a deadline, I like to probe a bit and see if I can ascertain whether it is a hard deadline, or completely bogus. Bogus deadlines hurt morale, unless your team just plain decides not to care about them. My advice to anyone in charge of a software project is that the right way to gain control over a software project is to take the time to understand the software development process or completely cede control to your head tech person and trust them.

As for the developers and other tech people, we are not without culpability. As a commenter pointed out in my last post, we need to be ready to communicate the business case for why we want to institute certain practices. We have to speak up and speak clearly, or there is no chance for improvement.

UPDATE: James Avery points out the necessity of deadlines lest developers gold plate like they are decorating the sistine chapel.

And I agree. Deadlines are important. This is the comment I left in his blog.

Well I do believe in deadlines. However, deadlines should be set based on realistic deadlines in which the developers give input and feedback. A deadline should really be an agreement between developers and management.

“Artificial” deadlines are those that are not informed by realistic estimates, but by wishful thinking.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



One response

  1. Avatar for David Vins
    David Vins March 16th, 2006

    As someone who has been on both sides of the equation as both a developer and as a business stakeholder, and having been exposed to both substandard development teams and teams that are the epitomy of excellence, I have the following two cents to add.
    First, this issue often boils down to the organizations ability to accurately estimate project effort, and the organization's trust in those estimates. Second, this thorougly rests on the amount of due diligence and scoping required.
    For example, on a past project, we couldn't even determine the size of an effort for a major feature until in one of our sprints, we took several guys and prototyped and dug into the concept of what we wanted to do. However, having spent that effort, we knew, with a reasonable degree of certainty, the size of that effort. Given that size, and some experienced development managers, the team was able to then determine how it was going to apply resources given the constraints of physical well being, work incentives, and time. There was a date we wanted to hit for business reasons -- but given a reasonable accurate sizing, we could then make tradeoffs versus other features and apply incentives (bonuses for PLANNED overtime, etc) that enabled the team to march forward and hit the date, and deliver high quality code.