How do you handle scheduling/deadlines around programmers? [closed]

Question

Do programmers like to create deadlines? Im a web developer, and schedules/deadlines are all over the place in my field. But I've worked with some software engineers/programmers who hate deadlines, is there a way around that?

Answer 1

Firstly, you need to distinguish between deadlines and estimates.

• Deadlines come from external sources, eg, "Feature X needs to be ready for the trade show".
• Estimates come from internal sources, eg, "Feature X will take N weeks to complete".

Generally, programmers should create estimates, and sales/marketing will create deadlines.

Problems occur when the two cannot be resolved - if the deadline is closer than the estimate.

Helpful hints for dev (leads):

• Let the person doing the work create the estimate.
• Ensure estimates are based on tiny tasks, each no longer than a day or two.
• Use a feedback loop to let developers improve their estimation skills.
• Accurate estimation skills lets you push harder against deadline demands.

Helpful hints for marketers / deadline creators:

• Don't override an estimate with a deadline.
• If a deadline conflicts with an estimate, the only real options are (a) developers work overtime, (b) the requirements for the deadline are trimmed, or (c) the deadline is missed.
• Explain why the deadline is important, and what the purpose of the feature deadline is ("customer X will sign a six-figure contract").
• Understand that people who feel they cannot meet aggressive deadlines will not be motivated.

Answer 2

Programmers HATE deadlines for very good reasons!

It's almost impossible to accurately estimate how long a piece of code will take to design, write and debug until you have done it.

From my personal experience I have spent over a week getting a "simple" shell script to work which I would have estimated at about an hour. On the other hand took about a week to write a parser for COBOL data definitions (including all the weird COMP COMP-3 OCCURS redefines SYNC and slack bytes stuff) which I had estimated at about two months.

The other big problem is that faced with a tight deadlines programmers skip best practice and start hacking. Thus saving about 50% of the coding time but adding 300% to the test and debug time.