5 ms·

Due dates are a lazy way to gain commitment

68 points by rmason 5y ago

gmfawcett 5y ago
A nice article. In part, the conclusion seems to be a rediscovery of agile. "What can we demo by next Friday?" seems awfully similar to "what's being delivered in the current sprint?" Just with less up-front planning & communication?
- SiempreViernes 5y ago
  It's not agile, it's Kanban! Says so in the image caption at the start. What the religious implications of this are I don't pretend to know, but I guess it has to do with how old you are.
  - gmfawcett 5y ago
    Ah! I didn't read the image caption. You're right, it's explicitly Kanban. There goes my insightful HN comment! (I will leave the agile religious implications for wiser heads, and just enjoy the sermon.)
commandlinefan 5y ago
"You need to commit to your due dates. But you also need to drop everything continuously to respond to critical issues."
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- MuffinFlavored 5y ago
  dance for that paycheck, human s/human/victim of capitalism
  - nicbou 5y ago
    Alternatives to capitalism don't have a great track record with quotas either. We're just victims of poor management.
TameAntelope 5y ago
Due dates are a reflection of reality onto the world of software engineering. "We need a demoable product by <Convention>." is not "lazy".
- tessierashpool 5y ago
  this is addressed in the blurb before the blog post even begins.
- deleted 5y ago
  [deleted]
- doctor_eval 5y ago
  Not at all. Writing software is a kind of halting problem - except for trivial cases, you can’t tell how long it will take to write some code, until you write it. Recognising this ”reality”, and building your software development processes around it, is _engineering_. Imposing arbitrary due dates on your team, based on partial information and guess work, is “management”. Management in this style can be done by any unqualified chump, and that’s why it’s much more common than engineering.
  - mym1990 5y ago
    A good system is where management and engineering can work together and be flexible, not where engineering despises management and management doesn't get what engineers are going through. Due dates aren't siloed to software development, they have been around for a long, long time. I don't understand how you would work within a team and show up every day saying 'this thing will get done whenever I am done with it, until then, please go away' and expect any kind of meaningful collaboration.
    - spoils19 5y ago
      > I don't understand how you would work within a team and show up every day saying 'this thing will get done whenever I am done with it, until then, please go away' and expect any kind of meaningful collaboration. That's how I've worked successfully for the last few decades of my career and I haven't had any problems. In fact, I once had a project manager try to enforce due dates or even ask us to demo what we're working on (despite the fact that we develop bottom-up so there's nothing to show!). That manager promptly got reassigned to another web team.
samatman 5y ago
Negotiating with a team about a reasonable due date on a deliverable is a good idea. If you skip the first 80% of the article, you'll find that this is a jargon-heavy way of suggesting that one does this, plus some cant around how it isn't really a 'deadline' since it wasn't imposed thoughtlessly from above.
tbrownaw 5y ago
> It’s important to note that when the date is the most important thing, the body of work must be flexible, and vice versa. You shouldn’t have both constraints. This will help bring clarity to the value. The last product-ish app I did (internal to the company), either neither of those was a constraint, or they both were. I was taking an existing manual process backed by an Access app, and making a web version that would assist with some of the manual steps. There was no inherent cutoff date. There were multiple possible levels of functionality. But every $PERIOD that it wasn't usable was another that the user team remained overworked, and every level not written was more of the manual work not automated. It eventually dropped to WONTFIX levels of my to-do list at somewhere around 1/3 of the potential functionality implemented. But before that it was at the very top, and the "due date" was "help we're bleeping dying over here". . I don't think that really translates to the proposed viewpoint in the article.
0xbadcafebee 5y ago
Some high-up executive says "We have to be in X market by Y date!" Everyone kills themselves to make the date. At the end, the product owner has to tell Executive that it looks like we won't make the date, no matter what we do. Executive says, "Oh, don't worry about it then, we just won't be first to market." A year later, a different team is tasked with replacing a legacy system with a new one. The team asks the Executive when the legacy system needs to be replaced. "Oh, well the legacy system still works, so we don't have a hard date. But it should be soon." Four years later, the team is still working on replacing the legacy system. The Executive comes to them and says, "Looks like we won't be using that system anymore, so we can sunset the replacement."
- thaumasiotes 5y ago
  > A year later, a different team is tasked with replacing a legacy system with a new one. The team asks the Executive when the legacy system needs to be replaced. "Oh, well the legacy system still works, so we don't have a hard date. But it should be soon." Four years later, the team is still working on replacing the legacy system. The Executive comes to them and says, "Looks like we won't be using that system anymore, so we can sunset the replacement." I'm struggling to see what's supposed to be wrong with this.
  - jrochkind1 5y ago
    I would say what's wrong with it is it was a waste of money/time to be working on the replacement at all, it turns out they didn't need it and did fine without it until it wasn't needed anymore. So the problem isn't that they should have finished it sooner, it's that in fact they shouldn't have been working on it at all, but spent four years working on something useless. so that's the problem... what the solution is and if it has anything to do with due dates, I don't know!
    - hallway_monitor 5y ago
      I guess it might seem like a problem if you are the director of software. If you're an engineer then that was four years of solid pay and benefits, probably with a bonus to boot.
tippytippytango 5y ago
I always thought the reason for due dates was to prevent the worst kinds of yak shaving from taking over a project's bandwidth.
easterncalculus 5y ago
>“What could we have ready to demo by next Friday?” >In fact, most team members will say, “I don’t know about next Friday, but if we aimed for demo on Tuesday we could show this cool new feature.” This is really doing a lot of heavy lifting. The author's idea of "most team members" is really "most team members that are already committed".
jrochkind1 5y ago
I don't disagree, this is not meant to be a challenge so much as coming it from another angle/context that I'm curious if others have had this experience: Sometimes I have found that without broad long-term phase due-date, features keep getting added forever. The due date can be helpful with product owner type people to get them to actually prioritize, decide which features are actually essential. Without a due date "oh, every feature is necessary", but if you say "OK, we had a deadline and we don't have X, Y, and Z done -- do we need to postpone it?" "Oh, no, we can totally go live without Y and Z" -- and then once you go live, they learn more about what the users really need and it turns out you never need Y and Z -- that without a deadline they were insisting you couldn't possibly go live without.
ivan_gammel 5y ago
> Each of the four had paused to consider the request, which indicated they did not already have a due date specified. Not a single one opened a calendar, consulted the delivery team, or discussed with their other three compatriots. At this point it would make sense to show them PMBoK or send to project management online course.
alexjurkiewicz 5y ago
Plans change, but planning is essential. In the same way, due dates change, but deadlines are essential.
tommiegannert 5y ago
Due dates are great as a synchronization point between teams who don't speak the same language (i.e. don't understand the details of each other's work). Most notably, a customer will be happier to hear "it'll be done by March 11" than "it'll be done when we have moved all the data from the old to the new database." It's a "lazy" solution, but not all customers want to have to care about your (internal) language. (And just like there may be scope creep in requirements, there may be deadline creep. You have to watch out for both. Just setting a due date won't solve your project management, and neither is just writing a requirements doc once.) For everything else, I agree.
tgsovlerkhgsel 5y ago
Due dates are - Budgeting. We're willing to spend our company's resources for X months on this. You can always do some improvements here and there and end up with forever-vaporware. A due date encourages forcusing on the most important parts and accepting "good enough" instead of getting paralyzed by perfectionism. - A necessity when there are multiple items competing for people's time and attention. If the development team has an important project and a project with a due date, there is a high risk that the important project will end up deprioritized compared to the one with the due date. That means you have to have a due date if you don't want to end up on the bottom of the pile. These are not laws of natures or impossible to work around, but you can either try to fight those effects... or just set a due date. Sometimes, the "lazy" way is better, because it works. That's why people set due dates.

68 points by rmason 5y ago

A nice article. In part, the conclusion seems to be a rediscovery of agile. "What can we demo by next Friday?" seems awfully similar to "what's being delivered in the current sprint?" Just with less up-front planning & communication?

SiempreViernes 5y ago
It's not agile, it's Kanban! Says so in the image caption at the start. What the religious implications of this are I don't pretend to know, but I guess it has to do with how old you are.
- gmfawcett 5y ago
  Ah! I didn't read the image caption. You're right, it's explicitly Kanban. There goes my insightful HN comment! (I will leave the agile religious implications for wiser heads, and just enjoy the sermon.)

commandlinefan 5y ago

"You need to commit to your due dates. But you also need to drop everything continuously to respond to critical issues."

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
MuffinFlavored 5y ago
dance for that paycheck, human s/human/victim of capitalism
- nicbou 5y ago
  Alternatives to capitalism don't have a great track record with quotas either. We're just victims of poor management.

TameAntelope 5y ago

Due dates are a reflection of reality onto the world of software engineering. "We need a demoable product by <Convention>." is not "lazy".

tessierashpool 5y ago
this is addressed in the blurb before the blog post even begins.
deleted 5y ago
[deleted]
doctor_eval 5y ago
Not at all. Writing software is a kind of halting problem - except for trivial cases, you can’t tell how long it will take to write some code, until you write it. Recognising this ”reality”, and building your software development processes around it, is _engineering_. Imposing arbitrary due dates on your team, based on partial information and guess work, is “management”. Management in this style can be done by any unqualified chump, and that’s why it’s much more common than engineering.
- mym1990 5y ago
  A good system is where management and engineering can work together and be flexible, not where engineering despises management and management doesn't get what engineers are going through. Due dates aren't siloed to software development, they have been around for a long, long time. I don't understand how you would work within a team and show up every day saying 'this thing will get done whenever I am done with it, until then, please go away' and expect any kind of meaningful collaboration.
  - spoils19 5y ago
    > I don't understand how you would work within a team and show up every day saying 'this thing will get done whenever I am done with it, until then, please go away' and expect any kind of meaningful collaboration. That's how I've worked successfully for the last few decades of my career and I haven't had any problems. In fact, I once had a project manager try to enforce due dates or even ask us to demo what we're working on (despite the fact that we develop bottom-up so there's nothing to show!). That manager promptly got reassigned to another web team.

samatman 5y ago

Negotiating with a team about a reasonable due date on a deliverable is a good idea. If you skip the first 80% of the article, you'll find that this is a jargon-heavy way of suggesting that one does this, plus some cant around how it isn't really a 'deadline' since it wasn't imposed thoughtlessly from above.

tbrownaw 5y ago

> It’s important to note that when the date is the most important thing, the body of work must be flexible, and vice versa. You shouldn’t have both constraints. This will help bring clarity to the value. The last product-ish app I did (internal to the company), either neither of those was a constraint, or they both were. I was taking an existing manual process backed by an Access app, and making a web version that would assist with some of the manual steps. There was no inherent cutoff date. There were multiple possible levels of functionality. But every $PERIOD that it wasn't usable was another that the user team remained overworked, and every level not written was more of the manual work not automated. It eventually dropped to WONTFIX levels of my to-do list at somewhere around 1/3 of the potential functionality implemented. But before that it was at the very top, and the "due date" was "help we're bleeping dying over here". . I don't think that really translates to the proposed viewpoint in the article.

0xbadcafebee 5y ago

Some high-up executive says "We have to be in X market by Y date!" Everyone kills themselves to make the date. At the end, the product owner has to tell Executive that it looks like we won't make the date, no matter what we do. Executive says, "Oh, don't worry about it then, we just won't be first to market." A year later, a different team is tasked with replacing a legacy system with a new one. The team asks the Executive when the legacy system needs to be replaced. "Oh, well the legacy system still works, so we don't have a hard date. But it should be soon." Four years later, the team is still working on replacing the legacy system. The Executive comes to them and says, "Looks like we won't be using that system anymore, so we can sunset the replacement."

thaumasiotes 5y ago
> A year later, a different team is tasked with replacing a legacy system with a new one. The team asks the Executive when the legacy system needs to be replaced. "Oh, well the legacy system still works, so we don't have a hard date. But it should be soon." Four years later, the team is still working on replacing the legacy system. The Executive comes to them and says, "Looks like we won't be using that system anymore, so we can sunset the replacement." I'm struggling to see what's supposed to be wrong with this.
- jrochkind1 5y ago
  I would say what's wrong with it is it was a waste of money/time to be working on the replacement at all, it turns out they didn't need it and did fine without it until it wasn't needed anymore. So the problem isn't that they should have finished it sooner, it's that in fact they shouldn't have been working on it at all, but spent four years working on something useless. so that's the problem... what the solution is and if it has anything to do with due dates, I don't know!
  - hallway_monitor 5y ago
    I guess it might seem like a problem if you are the director of software. If you're an engineer then that was four years of solid pay and benefits, probably with a bonus to boot.

tippytippytango 5y ago

I always thought the reason for due dates was to prevent the worst kinds of yak shaving from taking over a project's bandwidth.

easterncalculus 5y ago

>“What could we have ready to demo by next Friday?” >In fact, most team members will say, “I don’t know about next Friday, but if we aimed for demo on Tuesday we could show this cool new feature.” This is really doing a lot of heavy lifting. The author's idea of "most team members" is really "most team members that are already committed".

jrochkind1 5y ago

I don't disagree, this is not meant to be a challenge so much as coming it from another angle/context that I'm curious if others have had this experience: Sometimes I have found that without broad long-term phase due-date, features keep getting added forever. The due date can be helpful with product owner type people to get them to actually prioritize, decide which features are actually essential. Without a due date "oh, every feature is necessary", but if you say "OK, we had a deadline and we don't have X, Y, and Z done -- do we need to postpone it?" "Oh, no, we can totally go live without Y and Z" -- and then once you go live, they learn more about what the users really need and it turns out you never need Y and Z -- that without a deadline they were insisting you couldn't possibly go live without.

ivan_gammel 5y ago

> Each of the four had paused to consider the request, which indicated they did not already have a due date specified. Not a single one opened a calendar, consulted the delivery team, or discussed with their other three compatriots. At this point it would make sense to show them PMBoK or send to project management online course.

alexjurkiewicz 5y ago

Plans change, but planning is essential. In the same way, due dates change, but deadlines are essential.

tommiegannert 5y ago

Due dates are great as a synchronization point between teams who don't speak the same language (i.e. don't understand the details of each other's work). Most notably, a customer will be happier to hear "it'll be done by March 11" than "it'll be done when we have moved all the data from the old to the new database." It's a "lazy" solution, but not all customers want to have to care about your (internal) language. (And just like there may be scope creep in requirements, there may be deadline creep. You have to watch out for both. Just setting a due date won't solve your project management, and neither is just writing a requirements doc once.) For everything else, I agree.

tgsovlerkhgsel 5y ago

Due dates are - Budgeting. We're willing to spend our company's resources for X months on this. You can always do some improvements here and there and end up with forever-vaporware. A due date encourages forcusing on the most important parts and accepting "good enough" instead of getting paralyzed by perfectionism. - A necessity when there are multiple items competing for people's time and attention. If the development team has an important project and a project with a due date, there is a high risk that the important project will end up deprioritized compared to the one with the due date. That means you have to have a due date if you don't want to end up on the bottom of the pile. These are not laws of natures or impossible to work around, but you can either try to fight those effects... or just set a due date. Sometimes, the "lazy" way is better, because it works. That's why people set due dates.