What should the penalty/response for missing a deadline be? [closed]

Question

Deadlines are part of a fundamentally wrong idea about how to do software development. People new to, or outside of, the software development industry do not understand this:

Software is done when it is done, no sooner and no later.

If a developer has a task and a week to do it, and it looks like it will take more than a week, nothing can be done to change that. No matter how much harder the developer works, no matter how many people are added to the task, it will still take as long as it takes (in fact adding people usually makes it take longer).

Instead, read up on the agile development process. Software should be developed iteratively, and each iteration should be based on the results of the previous iteration, not on external requirements imposed.

Edit based on the extensive comments below:

I would never argue that developers cannot be held to some kind of delivery expectation. My point is in response to the specific hypothesis which the asker posed - that the nature of software development in business is somehow analogous to schoolwork, or any other kind of work for that matter. I contend that it absolutely is not. "Deadline" implies much more than a simple delivery date. It is a fixed point by which a fixed amount of work must be completed. Software simply does not work that way. I wrote a few more paragraphs explaining why, but honestly if you don't already believe that, nothing I say is going to convince you.

If you are working on a software project and it is clear you will not be able to reach your deadline, what can you do to rectify that? The answer is well-known by now: practically nothing. You can't add more people. You can't "work faster". It's just not going to get done on time. You tell the stakeholders, everyone adjusts, and keep working (or not). What, then, did the original date mean?

Anyone who claims software development is analogous to bridge-building or homework or that impending deadlines can still be met if the developers would just get their shit together and work their asses off, are deeply confused about their own profession.

Your first reaction should not be what to do in response to the missed deadline, but to analyse why you missed the deadline. The response to missing the deadline would then follow naturally from that as a consequence of the reason.

For instance, if everyone involved didn't do their job, fire them.

But if they did their job, and more, then why was it still missed? Too much other activities done by the same people? Too big a scope for the deadline (ie. unrealistic deadline). Or ... etc.

The top reason for missing a deadline in my experience is that people aren't allowed to work 100% on the project at hand, and thus any estimates you might have, although accurate on their own, aren't really useful at all. That, plus unrealistic estimates and deadlines.

Developers should never be penalized for Management's mistakes.

It's like a parent punishing a child because the parent had a bad day.

Reasoning:

Deadlines are a fact of life. People want to know how long something will take. The best we can do is estimate/guess. It is the role of management to try to figure this magical, never correct guess. When they create a deadline, they need to use the right tools (experience, ASKING FOR HELP FROM DEVELOPERS, lawyers, hr, etc)

However....

The penalty for missing a deadline should not fall back on the workers. It is the management's fault for missing deadlines. They should have said no, should have scaled back the project or should have motivated the workers better.

In a construction crew, if you piss of the workers, you start a fight. In my company, if we miss deadlines, the management gets in trouble. Not the workers. It's the manager's job to control the project and what is done. The workers are only doing what they can. The manager's are in charge of assigning roles and tasks.

I'm not saying the quality of workers isn't a factor, but the management should KNOW that! It doesn't take a genius to know that a project isn't well thought through or nicely controlled. Ask anybody if their manager has any idea what's going on and you'll find the problem.

We stopped missing as many deadlines when the managers realized it was their fault for setting/agreeing to the deadlines.

</rant>

Re: The questions:

1.What actions have you seen applied as 'penalty' for missed deadline, and which of these actually made things 'better'?

• Manager has less responsibility. This person does not get promoted or publicly thanked. Most likely this person will be moved to a "less-critical' project.

2.What project-management responses caused the project to fail outright, and what responses restored working order and resulted in code that could be maintained afterward?

• feature creep: manager keeps adding more stuff in the list. <- fight this off with a List of tasks ordered by priority. When you add things to the list, compare their priority with the things around it. Make new things harder to be set as "top priority."
• too many bugs in the code: Manager need to require tests (atleast critical) and automation. Builds need to be standard and automatic. Real users need to see the code before it is "finished."
• un-readable code: Institute peer code reviews. If someone has dirty code, ask someone to "help" them with a project.
• If you have the salesman problem, where the salesman promises features that doesn't exist/work: Management needs to step in and explain the problem to that salesman. Also, not giving that salesman public affirmation for a job well done sometimes helps this.

Rather than a penalty, how about realistic estimates and rewarding on-time releases?

---

Inspired by the comments to my response

Maybe the question should be "How do I make realistic estimates?" For me, I use FogBugz estimation history and completion date plots. These give me data points of how long I estimated a task to take and how long it actually took. This has helped guide me to give realistic release dates in the long-run (it didn't happen overnight). I find estimating timelines to be an interative process: I

1. design
2. estimate
3. develop
4. find an shortfall in the design & iterate.