4 ms·

Deadlines are effectively reality for many projects because tons of people and scares resources need to planned around them. Rallying against them is unrealisti

Deadlines are effectively reality for many projects because tons of people and scares resources need to planned around them. Rallying against them is unrealistic Let me give some examples: You're making a product for retail. The stores that will carry your product need to plan to have their shelves full of product. That means they need to know when your product will be available. What promotions will appear on posters, flags, etc in the store. They need the plan this 6 months in advance so you have to commit to a deadline well beyond your finish date. You plan to run commercials. The TV companies need to know sell their commercials months in advance. So you commit $$$$$$$ to pay for those commercials 6 months in advance. Miss your deadlines and there will be no product when your commercials run. You're adding features to a mobile OS. Your partners (Samsung, or Sony, or LG or Motorola) are planning all of the stuff above (PR, Commercials, retail placement). They are going to be touting your new feature. Because they have to commit to ads and shelf space months in advance you also had to promise your feature will be ready months in advance. I'm sure there are better examples. Here in Tokyo they getting ready for the Olympics. The venues, transportation changes, etc have a hard deadline. Video games used to (still?) have all the same issues. 6 - 9 months before Christmas you have to promise the stores your game will be ready and on their shelves. That may change in the future but even in 2019 retails sales of bluray PS4/Xbox and Switch SD games are greater than online for the majority of games. If you happen to be on a project that can run without deadlines and things get done and shipped whenever then lucky you.

quickthrower2 8y ago
If a project must have a deadline then I think there needs to be flexibility on what features are included. For some features you can only know how long they will take once you get started on them. The overall business requirement has a deadline, but individual features may not. The worst kind of deadlines I've experienced are we must have X by Y date, where the Y date is imposed by someone outside of the team without really thinking it through, and the only way to achieve it is via overtime and cutting corners. This can also happen when you the dev says "10 days" then they get haggled down to "2 days" by their boss. Having split the thing up into 100 pieces and have those pieces individually negotiated, you end up with a hack solution. That kind of project, one way or another is going to go to shit. It may be delivered on time but it'll be a turd. Or it will just be late.
- DoingIsLearning 8y ago
  > where the Y date is imposed by someone outside of the team without really thinking it through From my experience this is arguably the biggest factor I have seen for a project to fail. Not all realistically planned projects are successful but unrealistically planned projects become woolly very quickly.
- kybernetikos 8y ago
  > when you the dev says "10 days" then they get haggled down to "2 days" by their boss. Devs are typically optimistic in their estimates. Having someone who won't do the work put any kind of downward pressure on an estimate is a great way of getting uninformative estimates.
  - philpem 8y ago
    In my experience this is largely a function of environment. If you give a realistic estimate and constantly get "stop padding your estimates" or "this needs to be done quicker" in response, after a while you start giving hopelessly optimistic estimates.
    - kybernetikos 8y ago
      You might be right, however what I've often observed is that people will estimate a task based on how long it would take them to do it if that were their only responsibility. They often ignore the fact that they don't get a full days worth of solid, productive coding due to meetings, build problems, releasing, code review, recruitment, fire alarms, sickness, status reporting... As I recall, at IBM they used to give 3 estimates, best / expected / worst case, and then weight them something like 1/3/5 to get the planning estimate. One person I worked with recorded estimate vs actual for multiple years. They were frequently an order of magnitude out.
- philpem 8y ago
  It's truly amazing how few people can grasp the concept of the time/quality/cost triangle. If you want good quality in a short time -- it'll cost more. If you want cheap -- you have to compromise on the amount of time or the quality. I'd argue resource is a better metric than "time", but the point holds for the most part with either.
brightball 8y ago
It’s nuanced. Artistic things can have deadlines more easily because you can simply decide what constitutes good enough. Functional things have to work...or they aren’t shipping. They can decide good enough on refinements and UX...as long as it works. It that sense, there are very few real deadlines around functional things. If it doesn’t work, it’s not shipping yet...meaning it’s not really a deadline.
- dahfizz 8y ago
  Deadlines are also a way to manage resources and priorities. If something doesn't work, knowing when that thing needs to work by helps you determine if it's worth it to add more people or pay extra overtime, etc.
- karmakaze 8y ago
  [Pet peeve: nuanced is overused.] Not really, choose feature specs or choose a date, not both. Even non-artistic things can have dates, just look at Ubuntu (and now Java) releases.
  - brightball 8y ago
    And when Ubuntu has a date, if something isn't ready by that date it doesn't go into the release. Simple as that.
  - ergothus 8y ago
    > [Pet peeve: nuanced is overused.] I'm used to seeing (and feeling) the inverse: people are far too likely to sum everything up into a simple, but too often wrong, explanation (he says with irony) Care to explain your reasoning for why it is overused?
    - karmakaze 8y ago
      I agree that too often sweeping statements are made and there are cases where finer details matter, and... I see it as a form of one upsmanship, like wine tasting when the term is used. Other times, it's used to suggest that there's some detective work going on when the case is not so subtle or sometimes even incorrect. Or maybe I just have a narrower definition of subtle. I also prefer to use the term for analogue things rather than discrete ones. No matter how small a discrete case is clear cut.
LordHumungous 8y ago
Yeah this is a weak article. Engineering has always involved deadlines.

quickthrower2 8y ago

If a project must have a deadline then I think there needs to be flexibility on what features are included. For some features you can only know how long they will take once you get started on them. The overall business requirement has a deadline, but individual features may not. The worst kind of deadlines I've experienced are we must have X by Y date, where the Y date is imposed by someone outside of the team without really thinking it through, and the only way to achieve it is via overtime and cutting corners. This can also happen when you the dev says "10 days" then they get haggled down to "2 days" by their boss. Having split the thing up into 100 pieces and have those pieces individually negotiated, you end up with a hack solution. That kind of project, one way or another is going to go to shit. It may be delivered on time but it'll be a turd. Or it will just be late.

DoingIsLearning 8y ago
> where the Y date is imposed by someone outside of the team without really thinking it through From my experience this is arguably the biggest factor I have seen for a project to fail. Not all realistically planned projects are successful but unrealistically planned projects become woolly very quickly.
kybernetikos 8y ago
> when you the dev says "10 days" then they get haggled down to "2 days" by their boss. Devs are typically optimistic in their estimates. Having someone who won't do the work put any kind of downward pressure on an estimate is a great way of getting uninformative estimates.
- philpem 8y ago
  In my experience this is largely a function of environment. If you give a realistic estimate and constantly get "stop padding your estimates" or "this needs to be done quicker" in response, after a while you start giving hopelessly optimistic estimates.
  - kybernetikos 8y ago
    You might be right, however what I've often observed is that people will estimate a task based on how long it would take them to do it if that were their only responsibility. They often ignore the fact that they don't get a full days worth of solid, productive coding due to meetings, build problems, releasing, code review, recruitment, fire alarms, sickness, status reporting... As I recall, at IBM they used to give 3 estimates, best / expected / worst case, and then weight them something like 1/3/5 to get the planning estimate. One person I worked with recorded estimate vs actual for multiple years. They were frequently an order of magnitude out.
philpem 8y ago
It's truly amazing how few people can grasp the concept of the time/quality/cost triangle. If you want good quality in a short time -- it'll cost more. If you want cheap -- you have to compromise on the amount of time or the quality. I'd argue resource is a better metric than "time", but the point holds for the most part with either.

brightball 8y ago

It’s nuanced. Artistic things can have deadlines more easily because you can simply decide what constitutes good enough. Functional things have to work...or they aren’t shipping. They can decide good enough on refinements and UX...as long as it works. It that sense, there are very few real deadlines around functional things. If it doesn’t work, it’s not shipping yet...meaning it’s not really a deadline.

dahfizz 8y ago
Deadlines are also a way to manage resources and priorities. If something doesn't work, knowing when that thing needs to work by helps you determine if it's worth it to add more people or pay extra overtime, etc.
karmakaze 8y ago
[Pet peeve: nuanced is overused.] Not really, choose feature specs or choose a date, not both. Even non-artistic things can have dates, just look at Ubuntu (and now Java) releases.
- brightball 8y ago
  And when Ubuntu has a date, if something isn't ready by that date it doesn't go into the release. Simple as that.
- ergothus 8y ago
  > [Pet peeve: nuanced is overused.] I'm used to seeing (and feeling) the inverse: people are far too likely to sum everything up into a simple, but too often wrong, explanation (he says with irony) Care to explain your reasoning for why it is overused?
  - karmakaze 8y ago
    I agree that too often sweeping statements are made and there are cases where finer details matter, and... I see it as a form of one upsmanship, like wine tasting when the term is used. Other times, it's used to suggest that there's some detective work going on when the case is not so subtle or sometimes even incorrect. Or maybe I just have a narrower definition of subtle. I also prefer to use the term for analogue things rather than discrete ones. No matter how small a discrete case is clear cut.

LordHumungous 8y ago

Yeah this is a weak article. Engineering has always involved deadlines.