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.