> Don't set deadlines, make them set deadlines, document it, then hold them to it. Make the penalty for missing their own deadline big. Software time estimates

> Don't set deadlines, make them set deadlines, document it, then hold them to it. Make the penalty for missing their own deadline big. Software time estimates are a legendarily hard problem. Experienced developers get better at it, but still frequently miss deadlines, often by large margins. And you're somehow not only expecting beginner-intermediate programmers to be able to set accurate estimates, but enact "big" penalties if they miss them? And if your argument is that these are small tasks, and they should be able to figure out estimates for them, then I'd point you to the all the studies on software estimations that suggest that major project overruns are usually not due to lots of little tasks being 20% or 30% late, but rather on 1 or 2 tasks on the critical path being 1000% late. We're all familiar with this problem. If you've been programming long enough you've run into quite a few of these "gotcha" tasks, not matter how good you are. I think your other ideas are very good. Actually, I'd take some of the ideas from your last two points, and apply to the first. Instead of penalizing the developer for overruns, have them write up brief case studies that outline why there was an overrun, and put it on the company wiki. I think having to write up a case study is probably an appropriate "penalty" for something that may have been out of their control (although I really wouldn't suggest portraying this activity as punishment, but rather as a critical response to overruns). But "big" penalties for missed deadlines is just pointy-hair boss territory. Given the quality of your other advice, I have to believe you weren't referring to an actual big penalty, like docking pay or missing a promotion.