Being relatively new to the software industry I have come across a question of deadline enforcement:

Back in the idyllic age of academia, the deadline was the end of the semester and the penalty was a well defined 'F' (or local equivalent). Out here in the real world we need to make code our current and future peers can work with, I face the situation where deadline comes, deadline goes, and the project is still not finished.

Now what? On one extreme we could fire everyone involved, on the other we could richly reward everyone involved.

  1. What actions have you seen applied as 'penalty' for missed deadline, and which of these eventually resulted in more-good-code?

  2. What project-management responses caused the project to fail outright,

  3. What responses restored working order and resulted in code that could be maintained afterward?

  4. What responses resulted in more-bad-code?

+18  A: 

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.
It'll never happen. (still good to try lol)
I like it! This question is really about the situation where things have already gone wrong. Dont get me wrong, I am not intending to advocate command and control corporal punishment in an attempt to help moral, just trying to keep the question open for creative responses.
Arthur Ulfeldt
FogBugz "estimation history" and "completion date" plots help me narrow down more realistic release dates in the long-run.
I haven't read those. I'm just curious, do they cover the fact that every middleman that the estimate goes through will shorten it, sometimes significantly?
@280Z28 FogBugz gives a probability for each developer to meet a given timeline. If you historically under-estimate the time a task takes, you will have a low probability of finishing on time
+11  A: 

It depends on if the deadline was possible in the first place, maybe it was a fault with the planning and estimation of how long it would have taken. Make sure you know why the deadline was missed before deciding punishment


I am not advocating this, nor do I implement any of these, they are just things I heard that were interesting/odd

Just been reading and watching videos on release cycles (usually in FOSS), common things seem to be:

  1. Ridicule
  2. Wearing of a 'Dunce hat' for the week (for people not commiting in time)
  3. Banning from the tree (for ABI/API breakage and things)

Although I suppose that is open-source software for you!

Aiden Bell
a dunce hat? seriously?
Jeremy Cron
Yep...bean-bag culture in action
Aiden Bell
could you link the videos? sounds interesting?
Arthur Ulfeldt
Sounds like a great way to piss off the most important assets your company has. Good luck trying to retain them for more than a few months.
From wikipedia:The developers of the FreeBSD Project award symbolic pointy hats (Dunce hat) to other developers or themselves, usually in humorous intent, to highlight mistakes.
Aiden Bell
@Aiden, I'll have to add that to my list of reasons why I'm not a FreeBSD developer.I'll also add that to my list of reasons why I'm not running FreeBSD. If that's the culture of the organization that developed FreeBSD then FreeBSD is bound to resemble it is some form or another.
David Locke
@David - I watched a OpenBSD presentation by Theo and he was quite casual about having ridicule and being nasty as punishment for bad commits and so on during releases.
Aiden Bell
@Aiden, do that to me on a BSD project and I'll turn in my next contribution with a GPLv2+ license. Does Theo pay really well, or does he just have masochistic developers?
David Thornley
@David, I am not a BSD developer, nor do I implement any of the methods I listed!
Aiden Bell
That works well in open source, mainly because you're taking away part of the reason people work for free: to improve their reputation.
+1  A: 


I hope the phrase, "the beatings will continue until morale improves", illustrates why this is a bad idea.
David Locke
Morale improved.
Fake Code Monkey Rashid
Hah! First thing that came to mind when i read the title. If you're gonna humiliate your workers, might as well be explicit about it...
(-1) should be a comment.
@devinb, It's OK, I opted for negative rep protection (Community Wiki) before I posted.
+58  A: 

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.

Rex M
I do agree for the most part. Software is done when it's done. What I don't agree with is that deadlines are fundamentally wrong. A bridge is done when it's done, yet it still has deadlines. The trick is not removing deadlines completely, it's learning how to make them realistic and managing software so that you don't introduce feature-creep, etc.
Problem is, what's the definition of "done"? Feature-creep and scope-change can be a killer - that's what causes overruns on government contracts. You can't outlaw scope changes. You just have to know when to say NO.
Mike Dunlavey
I strongly agree with this. The vast majority of "deadlines" issued by bosses are made up. Followed by deadlines to meet conventions. That being said, we have a product that interacts with the government. Those deadlines are real, and set in stone. Missing them means our product is dead. We have one that our boss wouldn't let us start until this summer, for a major revamp of how the govt works. The developers believe that we should have started 2 years ago. The boss thinks we can be done next month. If our product isn't shipping by Q1 2010, we're out of business.
I would not agree Software is done when it is done, no sooner and no later. Sounds like a artistic behavior of a diva to me and not the behavior of someone who works for a company that relies on estimates deadlines etc...
Sometimes, a deadline is valuable not because it's accurate or achievable, but simply because it serves as a rallying cry -- something around which to motivate the team. I'm not necessarily defending this practice. Just making the observation that, for an entire class of people who set deadlines, this is what the deadline means to them.
Aaron F.
What about the case where a much larger, non-software project depends on the software? Surely that larger project's deadline must be taken into account?
Travis Beale
@Travis that is a recipe for failure. Your scenario doesn't change the truth, it just means a much larger pile of cash is now at risk. Any system which relies on software development should be structured to phase in response to the software's progress. The software cannot be organized to complete in response to external needs. Many try, and anything other than failure is total luck.
Rex M
I agree that "when it's done" isn't always an acceptable term, but the guys that made DOOM said "It'll be done when it's done," and now most of those guys are millionaires.
Bernard Dy
@Rex M: Enterprises need schedule information for planning purposes. They need to set realistic deadlines. What they frequently do is arbitrary deadlines (usually unrealistically short) or allow feature creep, and that is probably the single biggest cause of software disasters. That doesn't mean deadlines and schedules are bad per se.
David Thornley
@David enterprises only think they need deadline information because they approach software development from a non-SD mindset. I know - I work for a huge enterprise organization. The only good deadline in SD is so ridiculously padded and far out that it's as useful as no deadline at all.
Rex M
@Rex M: Software developers only think deadlines are unimportant because they approach software from a non-business mindset. People managing large projects that include software need to have a good idea as to when they can expect the software to be done. They also should have (and frequently don't) have an idea as to how rigid the deadline is, and what they can do to compensate if it's going to be missed. They should accept "It's done when it's done, and this is when I'm pretty sure it'll be done."
David Thornley
Deadlines (and indeed any fixed concept in the subject of risk) are doomed to failure. The trick in managing the software development process is accepting and minimising risk, not denying it in the name of a project plan.
In the absence of magic: If the deadline is not adjustable, then some other aspect (such as features) must be adjustable.
Chris Ballance
@David: I tend to agree. The last time I had no deadlines was in grad school (and I have to say I didn't accomplish much). I don't know any business that's willing to support people without some assurance of ROI in reasonable time.
Mike Dunlavey
The idea that deadlines are unrealistic or from a non-SD mindset shows the wrong focus; deadlines are a fact of the business world and they are here to stay, for better or for worse. Accept that fact and treat estimating as a skill to be improved just like any other.The flip side is that managers need to know estimating is an NP complete problem and can be approximated but not solved. As such, they have to accept failure a certain percentage of the time.Also, what Chris said is helpful. Deadlines should only apply to the most vital features that CAN'T be cut; the rest is extra credit.
deadline, *n.* "A boundary line in a prison that prisoners can cross only at the risk of being shot."If the project is important enough that it can't be killed/shelved if incomplete on the due date, then setting a deadline is just feel-good busywork for someone without any real control over the work being done. Otherwise, you just want a predicted completion dates to help with scheduling, one you can easily change when circumstances require it...
I Agree with Shog. There are very few applications that have a *real* deadline. Meaning: lost business. As others have said, look at iterative development processes. The goal being, for each iteration deliver ONLY what's been agreed on before hand and ONLY the parts that are absolutely necessary for the next step.
Chris Lively
"Software is done when it's done" is a poor way of looking at it. It might sometimes be right, but many of the best devs can find infinite ways to tweak something, and literally need to be told to stop. This kind of passion is great but it needs to go *across* version numbers, not squeezed into a single release.
Chris Burt-Brown
@Chris that's not what we're talking about. Anything can be improved. This is about creating software that meets specifications. "How long will it take your team to build software that does x?" We don't know. We'll know when we finish writing software that does x.
Rex M
This is particularly tricky when dealing with flat-rate development projects. "It's done when it's done" means you're going to lose a lot of money.
Sam Schutte
+3  A: 

So far in my career I haven't seen any real penalties for missing a deadline (and I've missed plenty). I imagine it's different for companies building software or games to be sold in stores where the company has made promises to the public.

But in the custom software development realm, it's so hard to accurately estimate how long a project is going to take. And often times this fact is reluctantly accepted by companies everywhere.

Steve Wortham
+14  A: 

Depends on whether developers set deadlines on each modification request, or whether these are set for them by management.

In the latter case, unless all your developers are sitting and playing Halo 3 all day, a missed deadline is often an indication of a mistake on the side of management or the team leads. So firing everyone wouldn't solve the problem. It might make sense to introduce better indicators into your software process so you could see that the deadline would be missed long before it happens.

If your developers do give time estimates, then I would be very careful about rewarding and penalizing developers for meeting deadlines or missing them. The result of doing this could be that they would adjust their "fudge factor" in time estimation. They would give themselves too much extra time (to reap the rewards), which messes things up if they are good at estimation. Your goal should be to get them to give good and reliable estimates, not to change the way they work to meet these estimates.

+9  A: 

Death. Clean and simple.

Donnie DeBoer
"What happened to your last project team?" "Oh those poor sons of...well that's not important. The important thing is, I need a new team"
Exactly. Just like a pirate crew.
Donnie DeBoer
We release the ninjas when deadlines are missed.
(-1) Should be a comment.
Thanks for enforcing the rules. Wouldn't want things to get out of hand.
Donnie DeBoer
@Grant - +1 for a Futurama reference!
John Rasch
Doesn't this mean we all have to shoot ourselves in the head now? Who hasn't missed a deadline?
Imagist = @devinb;
-1 because it's not helpful, but +1 because it's funny. final score = 0 ;)
Stefano Borini
Cheers Stefano!
Donnie DeBoer
@John Rasch, I was worried that I butchered it too much to be recognized.
@John, @Grant I'm glad I'm not the only one still quoting Futurama. Thanks for that glimmer of hope...
James Schek
+34  A: 

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.

Lasse V. Karlsen
Aside from blatant incompetence, firing everyone involved sets the project back significantly further.
Chris Ballance
Deadlines really need to be adjusted as the project scope changes. When something unforeseen comes up that will increase the amount of time required, management needs to be made aware so they can make a decision (extend the deadline, cancel or shelf the project, add resources, etc.).
I think you touched upon an important point--accurate estimates. There's a bigger question in Software Development as to how reliable an "estimate" really is. For a deadline to be meaningful, the estimates provided must be accurate. Too often, developers don't know how to give estimate and management refuses to wait for and to provide resources for accurate estimates.
James Schek
+4  A: 

Once you've reached the point at which people have blown the deadline, you have to ask yourself (A) what the natural consequences of that are and (B) how you can best complete the task and maintain some kind of movement towards the business objectives (even if you're not running a business).

Explicitly penalizing people for blowing the deadline is unlikely to help unless they believe that they've earned it. This will not happen if the deadline was unrealistic, if there were elements of the team that were the primary points of failure, if there were serious problems with requirements, or if the majority of the team involved believes that the above factors are true.

In one case I was on a team that blew a deadline on a small deliverable by over three months - and the original deliverable due date was three months from start! We misunderstood the requirements, didn't sufficiently talk to the customer, and underestimated the time involved. Management was not at all interested in assigning blame. This was partially because it would have been counterproductive to finishing the deliverable, partially because none of us were "problem employees", and partially because management knew that we were all highly-motivated to fix the problem and satisfy the customer. So we got it done, the customer was as happy as could be expected, and we moved on with our lives, with some valuable lessons on how to avoid the situation in the future.

+2  A: 

Once a project is late, there is not much 'management' (good, bad, well meaning or malicious) can do, that will not result in the project being even later

... the only exception possibly being the removal/avoidance of exterior distractions.

+7  A: 

Oh, man...

First of all, there are external deadlines and internal deadlines, and they should be different.

What happens with an internal deadline is the frequency of activity increases as the deadline approaches, reaches a peak at the deadline, and then falls off as the deadline recedes. So plan the external deadline to follow the internal deadline by a couple weeks at least.

Then, make sure the deadlines are realistic. Partly you do that by involving the developers in setting them, and in deciding what will be accomplished.

Finally, I've mostly been a developer, but once when I took a stab at management, I would never want to take the latest-and-greatest version into a conference or presentation. I would want to take a version that was at least a few weeks old and that I knew where the problems were and that I could be sure would not contain unpleasant surprises.

Mike Dunlavey
This was really in Internal deadline.
Arthur Ulfeldt
@Arthur: In that case, I think it is perfectly "normal" for it to be missed. What my boss (a good one) does is set a date for things to be finished, knowing full well that it won't actually be needed until a week or two later.
Mike Dunlavey
+4  A: 

In his wonderful book about project management - "Deadline" - Tom DeMarco tells us a story, about project manager from a western-world is managing a project in some fictional post-communist eastern European wild country (wild is a really good term, because the citizens are a bit.. uncivilized).
One day PM discovers, that something went wrong, some part of his project dramatically missed the unrealistic schedule. Previous PM established penalty for missing deadline simply by hanging responsible person on a butcher’s hook, but as schedules were unrealistic, one man already missed deadline.
So the story tells us about a day, when western-style PM is presented with a responsible person, and he should send him to be hanged on butcher’s hook. PM, as most people do, is terrified of vision of sentencing someone to cruel death simply because some was never able to finish his project in time. And – by all means – hanging this poor man does not advance the project. Since this is a fiction novel about project management, and not about tortures, our hero cancels the penalty.
But there is some big issue behind this story about hanging someone: if you set a deadline, and establish some kind of penalty for missing this deadline, the day will come, you will probably have to actually punish someone. And will you do it? No matter what the punishment will be: hanging, bonus loss, firing, breaking the deal or some fee – you may have to punish someone. Will this penalty do some good to your project? You have to answer it by yourself.
So: do not establish a penalty for missing the deadline, you will not want to execute…

+18  A: 

Developers should never be penalized for Management's mistakes.

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


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)


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.


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.
nice answer, I like to see this new approach. Can I iterate the question again, though directed toward a PM?
Arthur Ulfeldt
I don't know if I can get behind the idea that a missed deadline is all management's fault. Managers, especially non-technical managers, can only estimate as effectively as the information they get from the team is accurate. Assuming that "the team" gives 100% accurate information certainly makes me look good, but I don't think its true.
+5  A: 

As others have mentioned, before talking about penalties, start with "how do we determine whether these deadlines are realistic"?

Or as my boss once said, "We'll be happy to work a plan when you give us a plan that works".

I still think that should be on a t-shirt.

+1  A: 

There are two possibilities:

  • The deadline was missed because someone didn't do their job.
  • The deadline was unrealistic.

Rather than thinking in terms of penalties, I would suggest doing a post-mortem to determine what went wrong and finding ways to improve the next deadline estimate.

Travis Beale
how about a third option? - the deadline was unnecessary
Arthur Ulfeldt
Good point, however many of us don't have the luxury of making that determination.
Travis Beale
I can make that determination, its just unlikely that anyone will liten or care about it :(
Arthur Ulfeldt

Two obvious questions come to mind when a deadline was missed:

  1. Was the deadline feasible?
  2. Did external factors impact performance?

Obviously, if someone presents you with a deadline that doesn't make sense then there shouldn't be any penalty for missing the deadline. Also, if someone misses a deadline because they were called up for jury duty that also shouldn't be held against them as well.

In the event those questions don't apply then the next thing to do is to figure out what went wrong. If you based your estimate for how long something would take, and thus the deadline, on the developers estimation of how long it would take them to write the code then perhaps they were too optimistic in their responses.

+2  A: 

No penalty. "Deadlines" and estimating have been and continue to be one of the hardest and most challenging parts of software development.

It is ridiculous to impose penalties on developers for this issue.

+1  A: 

You ask "what should the penalty be...". It would appear you are asking from the perspective of "inside the company".

In real life, the penalties are often swift and severe - loss of business, lawsuits, bad reputation in the industry. These are the REAL penalties imposed by clients who were promised something by a certain date that was not fulfilled.

Internally, you can often do whatever you like. But once you start involving paying clients, then managing those clients becomes a critical part of the overall job.

Penalties such as I described can often be avoided (or lessened) by "on top" communication with the client. If the client wants something added (so-called feature creep), then this should immediately be answered with the impact these changes will have on the project (costs more, delivered later, whatever). The client should be encouraged to triage all such requests against their deadlines and projected costs (i.e. let the client manage feature creep, not you).

If other things change the delivery time, then as soon as you know there will be slippage, you must inform the client. If done early, clients are remarkably willing to work with you. But if you don't say anything until it's too late, they are less likely to forgive... especially should they discover you knew a significant time earlier and didn't tell them.



Yes, I am asking from inside the company. I dont really know what the external effects are, perhaps this is a separate problem. So are you saying that If I'm in the situation where things have already slipped then we should find out what the external will be and appolagize profucely?
Arthur Ulfeldt
If there are external perties involved, then (hopefully) management is already fully aware of penalties and in fully communication with the external parties. If not, you may already be in deep trouble. Then internal penalties will be moot.
+2  A: 

If you're missing your deadlines, fix your estimates.

+3  A: 

Taken from a corporate development standpoint...

If the deadline came from someone other than the person performing the work, review the situation to determine the cause of the overrun. In these cases, it is often related to incomplete requirements, scope creep, poor management, etc. No punishment should be given for missing a deadline that the person never provided in the first place.

If the deadline was provided or agreed upon by the individual performing the work, then that person needs to explain the factors that led to the delay. In addition, this person should be reminded to notify their supervisor, project manager, or other responsible party as soon as they are aware that a deadline may be missed. This information should not come to light after the deadline has passed. If this occurs repeatedly, your company's disciplinary process should be followed. This may involve write-ups, suspensions, or termination.

People tend to take real ownership of deadlines when they are the ones setting them. When deadlines are placed on them without their input, deadlines tend to become meaningless to the person performing the work.

One thing to note that the person providing the estimate for the deadline should also know how to give accurate time lines. A new developer may not be able to accurately estimate them yet.
+1  A: 
  1. I've seen executives leave a company shortly after some deadlines were missed. This changed everything but didn't necessarily make things better or worse. I've seen some contractual obligations like clawbacks as a way to penalize someone for missing a deadline that I'm not sure how well they work.

  2. When one completely changes what a project is supposed to do midway through the alloted time for the project that tends to cause the initial trajectory to no longer be valid and thus the project will fail because it likely will not meet the initial deadlines within budgets. Replanning the project into short increments of at most a few months is a response that I believe is a logical direction to take a project to get good results as a lot of project may have to accomodate changing requirements which can easily change deadlines, head count or time worked.

JB King

Lack of Software is enough of a penalty.

I think most people have bad understanding of software estimates.

How long does it take to Design a commercial passenger car? How long does it take to build?

There is a difference...

When you are building a Commercial passenger car your basic requirements are already known you are basically assembling parts already designed to fit together and also know what order to perform the assembly.

And if you do a good job, it's easy to maintain when done; (You can change the spark-plugs with-out removing the entire engine, if the timing belt breaks you don't fubar the engine).

+2  A: 

While I have never seen any disciplinary action or firings I have seen lots of "mandatory" overtime and peer pressure to work longer hours.

I almost got fired as a manager for telling the team that reported to me NOT to come in on weekends and work late. I know those things are detrimental to the project and to morale.

Generally the "punishment" is in the form of making people feel guilty or anxious, but I am sure there are places that do more "official" things.

The world is full of idiots. Management is no exception.


The penalty should be based solely on the purpose for giving (or asking for) a deadline in the first place.

Greg Miller
+3  A: 

I think the question it self demonstrates a misunderstanding of the role of management and project management.

There is, unfortunately, a common perception in the minds of many with the word Manager in their title that management means putting the heal to/kicking the butts of lazy workers. It fits with those that believe in Parkinson's Law as well.

It's not. It's about making it possible for works to do their jobs - be it being the communication channel between them and some other part of the organisation, getting them resources, or running interference (moving the furniture out of the way).

To wit, the PM should already know the project/task is going to miss it's deadline. They should be asking questions, and know what's going on. They have the power to either cut tasks or increase/rebalance the resources to get the job done (or say to the sponsor, if you don't give the resources, it ain't getting done on time). And as such, the penalty goes to the PM, whether it is nothing, tongue lashing, demotion, or termination.

Sometimes the delay is unavoidable. This is why we build in contingency time. Sometimes, it's a known risk; and so long as you have a backup plan - you are OK.

As for the responses, you have four parameters: Scope, Time, Money, and Quality

  • Scope - you can cut to make the deadline.
  • Time - is fixed. You might be able to get your staff pull a week or two at 60hrs, but your productivity will begin to suffer after that. And it also costs more money if you are paying them fairly.
  • Money - You can buy pieces from someone else to speed up the process. You could even hire more people, if the work is disjointed enough that you don't have to have a lot of communication with the existing staff - see Brook's Law
  • Quality - Idealistic fools claim you can never skimp on quality. But you can. You don't have add bugs (one form of anti-quality); but you can put less quality in. Do you code your function so it can handle unlimited length strings, or is 100 characters good enough for this version? Do you make it easy for the next upgrade to bolt on a new module, or do you weld it shut and worry about adding a plug-in module when you do the next version.

Not doing these things aggressively enough (when required) will surely lead you to a failure.

+1  A: 

What should the penalty be for setting an unrealistically short development timeframe against all of the advice of the developers and their leads?

Coincidentally, this seems to happen almost as often as development teams missing ship dates.


castration, after that they will never miss deadline.


"Who does what by when" is a question that each project team member must provide a professional commitment/response to in any profession. As far as when a deadline is missed use that evidence to improve the estimating process and ask the individual to make a new commitment. This assumes that their was in fact a commitment made to the previous deadline. A great series on 'Who does what by when' is available at manager-tools.

Also, I would recommend that you distinguish between Estimates, Targets and Commitments. And manage the 'gap' or the risk between the estimate <--- gap ---> commitment. Look at Software Estimation: Demystifying the Black Art.


They will miss a deadline at most 2 times, after that they can miss as many deadlines as they like...

That's ridiculous.
You may punish me for missing a deadline exactly once; after that you are down a good programmer.
Jay Bazuzi
Are you trying to say "Three strikes you're out"?
Sam Schutte
+2  A: 

It's certainly not a cut-and-dry answer. Here are some things which I weigh and things I do/encourage in order to make sure things get done on time.

1.) Set priorities properly. Projects will always have various degrees of completion. It's not a binary "done"/"not done" switch. If the highest priority things are done first, it's easier to swallow. Ideally, you should quickly get to the point where it works, but it doesn't do everything we need it to do and it doesn't look pretty. Once there, it can be released if it absolutely needs to.

2.) I've found that the best way to handle it is to make the releases as small as possible. This makes the estimates more accurate. If your boss or "the market" dictates that your estimate is unacceptable, consider assigning more developers to this task if possible. Sometimes a task can't really be divided up easily, or there's only one person familiar with the code. If it's not a high priority just tell the powers that be that it's going to take longer. Setting reasonable goals and managing expectations is key.

3.) As for motivation, rewards, and punishment... there are many doctors who have written entire books on these subjects. In my experience, giving programmers something which is challenging and letting them have some freedom to do it their way is a good start. Listening is something managers need to do well in order to succeed. If the developer is seasoned, you should be able to just explain the problem and let the developer come up with the solution. If their solution isn't as good as what you had in mind, you can suggest it and go from there. Just dictating how to do something, even for new programmers, is seldom effective. Making the developers think about things will help them be able to solve problems on their own. This is related to delegating, as that only works if the developers can do the work on their own.

4.) Reduce turnover by paying people well if they're doing well. It usually costs much more to find good people. It takes time to get familiar with a large code base and the hiring process can also help avoid spending time on people who can't cut the mustard.

5.) Ask (don't demand) if a developer can stay late/work weekends. Only do this when it's something very critical (for example a security flaw which gives user access to data they ought not be able to access; a new law/regulation passes which you must comply; etc.). If they say no, don't hold it against them. It's likely not their fault that things didn't get done; and even if it is, it's reasonable that they made plans for time when they aren't expected to be at work. If they are willing to come in, make sure they know your sincere appreciation. Compensate them well for helping out when they aren't obligated to, buying lunch doesn't cost much and it's a very nice gesture. Don't make a habit of expecting people to work late/weekends unless it's part of their contact/agreement (or if they like doing so).

6.) Understand why things are running behind schedule. Did you promise something which wasn't possible (given the people available, quality expected and time allotted)? Did some other project come up and take up resources and the deadline wasn't adjusted? Was the code just harder to do than expected? Giving time estimates is difficult. You need to plan everything out, have experience and know how long each developer will take for the task. Compensate for unexpected problems which will likely arise and give the programmer a sooner deadline than your boss or the client. It's always OK to be done early. And if you're almost always done early or on time, that one time that you missed your deadline will be more understandable if you have an explanation of some sort.

7.) Remember, it usually boils down to time, quality and money. You can generally pick any two, but the third one will need to balance the equation. So if it needs to be done quickly and on a shoestring budget, you can expect the quality to suffer. If you need it done quickly and of high quality, expect to pay a lot of money, and so on.

8.) I'd say the #1 thing which works for me is listening. If your too busy barking orders then you might not even know about problems with the company. Now just because a developer says "the code sucks, the design is terrible and we need to re-write everything if we want to get anything done in a timely manner" doesn't mean that it'll happen. But if you hear comments like that and explain that we can't afford to do this or we'll get killed in the marketplace, it'd be way too expensive. And ask what can be done to make sure things don't get much/any worse. Ask if there's a way we can clean it up over time. Can we just (re-)write one class and build new stuff based on that? Can we slowly migrate to a new design one feature/segment/module at a time? You understand where they are coming from and vice versa, you can probably solve at least some of the issues. Just remember that compromising works both ways.

9.) Negative re-enforcement seems to result in higher turnover, which is costly. Having a bunch of people who aren't familiar with your code doesn't help deadlines either. Money is one motivator, but I've quit a higher paying job to go to one where I'm happier before, and I know I'm not alone there. Free food when the team does a good job isn't really that expensive. I'm not too keen on group activities since they're either cutting into an employees time, or taking away from work time. It works sometimes, but cutting into an employees personal time so they can hang out with co-workers instead of being with their friends isn't that great of a reward. Having everyone stop working is also expensive... so it just depends on the company size, culture, etc.

Hopefully that helps answer your question. The other answers in this thread are also good suggestions... design plays a big part in how quickly code will be written.

Dr. Nichols

You talk about deadlines and code quality as if they are part of a zero sum game where you have one or the other. Just to take half-a-step back, a project’s overall success is based on the overall benefits provided to the company/community – benefits should be clearly determined at the start of the project and COULD include quality code or time to market or functionality or overall-quality or any combination. The cost/effort is estimated based on what is being aimed for, the environment and the people involved…there is NO WAY to exactly determine costs or timeline (you can’t predict the future), but you set them as guidelines to help navigate and ensure the final benefits are not outweighed by the effort. To your specific questions:
1. – what penalty actions have I seen used? From firing to no penalty – in most cases I’ve seen no action taken which is probably the biggest cause for project failure (answering #2)

2 – project management response that has caused a project to fail – no action or focus on setting some future arbitrary timeline without correcting or addressing why the initial timeline was not met.

3 – what response restored working order? Root cause/risk analysis, getting to what the base issues of the project straying are. Timelines and costs are just indicators that a project may be having issues, there are others more meaningful ones such as overall quality, team moral and communication that would indicate a project in duress.

4 – what response resulted in more bad code? No response OR a focus on hitting a deadline instead of delivering on the intended benefits.


This is not really a programming question, but more of the management question.

Missed deadlines are rarely developer's fault. As a developer you should try your best to do as good work as you can, but in the end everyone is capable of only so much. If developers put in honest effort and despite this the deadline was missed, it means that the deadline was unrealistic to begin with.

Dealing with deadlines is responsibility of managers. There are different approaches but none of them include "penalizing" developers for doing their job. An important thing to understand here is the so-called project management triangle. What it means is that software project can be good (i.e. meeting requirements, good quality), fast (meeting deadlines) and cheap (headcounts, tools). The trouble is that only 2 out of these 3 properties can be chosen.

So if management want something good and fast - it is not going to be cheap.

If management want something good and cheap - it won't be fast.

And finally if management want cheap and fast - guess what, it won't be any good.

So the correct response to missed deadline depends on the chosen scenario. Good and fast requires adding some extra help, better tools, investment in above-average developers and more.

Good and cheap by definition assumes that deadlines are going to be missed (Blizzard, makers of World Of Warcraft are good example of this approach)

And finally cheap and fast usually means cutting features and releasing with bugs.

Gregory Mostizky

Did the specification or requirements change after the estimate was given?

Michael McCarty
+1  A: 

The main goal of project management is to plan how an application is going to be built, in time. You should not start your project development if you don't have a schedule showing what you're going to be doing every single day the project will last.

This way, you can detect that you're going to be late, as long as you follow the project's evolution on a regular (weekly if not daily) basis. And the earlier you know it, the sooner you can act accordingly.

You usually have two options :

  • Catch up (by hiring additionnal workers, working more, or removing features).
  • Tell your customer that something went wrong (even better : what went wrong) and you're gonna need more time.

For the second option, I'm not meaning there won't ever be penalties. But from my personal experience, as long as the customer is informed in advance and offered solutions (preferably three : give more money for additional workers/remove features to save some time/accept the project being late), they'll be open to negociation. Which is always better than conflicts :)

+1  A: 

Perhaps the better question is if deadlines are meaningful in the face of inaccurate estimates? Businesses do a lousy job of estimating software--that is a fact. Both management and developers play a part in this and neither one seems willing to own-up to their responsibility in this problem.

But to answer your specific questions:

1.What actions have you seen applied as 'penalty' for missed deadline, and which of these eventually resulted in more-good-code?

The 'penalty' I've seen for missed deadlines for managers and developers range from nothing, to promotion, to simple transfer. The most severe penalties I've personally witnessed was a manager "transferred" to a less important project and for the business-unit to lose a financial bonus.

The only time I have ever seen someone fired over a missed deadline was when the employee was already going to be fired--the deadline gave the business a legal reason to fire the employee.

2.What project-management responses caused the project to fail outright?

This is a whole separate discussion on its own... but there is some inherent bias in this question--project management is at fault.

The three top things I have personally seen PM's do that sabotage a project are (in order of severity):

  1. Ignore data/recommendations/warnings from their technical staff.
  2. Ask for estimates early in the development process. This results in estimates with an error-bar of 10x (it'll take one month, give or take ten months).
  3. Reject/modify/demand software estimates so that they fit an arbitrary budget and schedule. This is not to say Developers should ignore business demands--but rather the business demands need to be set equally by Developers and non-Developers.

3.What responses restored working order and resulted in code that could be maintained afterward?

I have yet to see a functional software development organization. So the fix is usually a lot of blood, sweat, and tears from a couple of heroic developers working with a highly-capable PM who knows how to defend against politics within the company (i.e. deflect BS from their staff).

4.What responses resulted in more-bad-code?

  1. Yelling. Cursing. Insults. (Sadly, this still happens in some workplaces)
  2. More "project management"--either by way of people, meetings, status reports.
  3. Getting software estimates earlier in the process so "we can plan better." Estimates need to come later when your staff has more data and a better understanding of the problem.
  4. Coddling the developers (it's not your fault, the manager screwed up).
  5. Coddling the project managers (it's not your fault, the developers screwed up).
  6. Adding additional, unqualified staff to the project.
James Schek

Your question is inherently flawed: it assumes that punishment is the best way to manage people. In general, that people don't respond well to punishment or threats of punishment; it brings out the worst behaviors, make the motivation external, and distracts from internal motivation. Rewards and bribes (threats of reward) are the other side of the same coin, and do no better.

These forces are built in to work for hire, however, so you'll never get the best creative work out of your programmers, but you don't have to make it worse by punishing them when they miss a deadline.

Instead, meditate on the creative process, the chaos of multiple people doing creative work, and what tools are effective in managing chaos.

To manage any chaotic system, do lots of measurement and be ready to change course quickly. In the case of programming:

  • Take the smallest steps possible. Don't "break the task in to small steps", as you'll waste a lot time planning steps that won't work out like you planned. Chaos, remember?

  • Pick the smallest steps that deliver the most value.

  • after a short period, reevaluate your plan based on what you've learned

  • deliver working software to actual, real customers as soon as possible, so they can tell you what you should really be doing.

You may recognize this as the thinking behind SCRUM.

Jay Bazuzi

The project manager should have a penalty for wrongly computing the deadline, not for missing it ...