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?
How do you handle scheduling/deadlines around programmers? [closed]
Asked Answered
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.
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.
-1 It's also up to us devs to improve the way we do estimates. It's not "almost impossible", it takes practice. I'd be able to estimate some task almost exactly because I know exactly what will happen thanks to my experience. I don't hate deadlines as they help me focus on an objective, I hate unrealistic deadlines set my marketers :) –
Heliocentric
Newbie or not, when I searched new solutions for unfamiliar bugs, my boss keeps pushing me to ask about the deadlines. If I'm being too honest, it will cost my job. What can be expect? We're programmers and have completely mismatched time because of one thing: excessive thinking. –
Tapping
Agreed! You can never estimate a task which you have never done before. It is easy to estimate CRUD websites but cannot things which you have to research about. Until you know how to do it, you cannot give proper estimate. Same happens when me when I am in rush. I just write fast code without even basic testing and then refactor the mess for days\ –
Lame
Traditionally you can only adjust quality, features or time, the last being the deadline. Quality you really don't want to mess around with. So as long as the process you're using allows you to calibrate features to reach deadlines, I'm ok.
Developers need to be involved in creating the deadlines. If they are arbitrary and created without input from developers then they have a right to complain. Projects legitimately get time constraints from business, but resources and features must be adjusted to compensate. Those adjustments can't be made without input from developers (not to mention BAs, QA and operations folks).
The only software engineers/developers I've met who hate deadlines feel that way for one of two reasons:
- They are completely disorganized, and know that they won't meet the deadline, and so don't like them because when they miss the deadline it makes them look bad.
- They don't have a problem with deadlines, as long as someone who understands the work involved is setting the deadline. The worst deadlines are made by managers trying to sell a project and saying "3 weeks? No problem!" and then telling their development team that they have 3 weeks to produce a working version of MS Office and recreate the internet for the CEO's little kid.
I think it depends on how the schedules are created. The developer needs to have a significant role in coming up with the schedule. Otherwise how will you know if it's reasonable or not?
If someone in upper management simply dictates that "Feature X needs to be done by Y" without having any good insight in to how long it might actually take (some things are a lot more complicated to implement than they sound like) then that's a Bad Thing. However, if they work with the developers to estimate the amount of effort actually required and balance that with the rest of the company's needs, then it generally works out pretty well.
Well, I'm quite happy with a deadline if that deadline has been determined through well thought-out estimate process with input from both managers and engineers and the requirements for what is supposed to be delivered on said deadline are well defined.
Regular reviews are crucial:
- List the major milestones and deliverables
- Break it up into smaller chunks
- Create a collection of smaller estimates
- Make the deadlines reasonable
You must have deadlines, but equally those deadlines must be realistic and measurable. Moving the specification around is going to annoy the developer - it might be unavoidable, but don't be afraid to move things (after discussions).
Deadlines and work estimates are never going to be particularly accurate, but so basic Project Management techniques should mean that people are aware of missing them - and why it happened.
© 2022 - 2024 — McMap. All rights reserved.