[HN Gopher] Due Dates Are a Lazy Way to Gain Commitment
___________________________________________________________________
Due Dates Are a Lazy Way to Gain Commitment
Author : rmason
Score : 27 points
Date : 2022-04-13 18:47 UTC (4 hours ago)
(HTM) web link (tristanhood.substack.com)
(TXT) w3m dump (tristanhood.substack.com)
| tippytippytango wrote:
| I always thought the reason for due dates was to prevent the
| worst kinds of yak shaving from taking over a project's
| bandwidth.
| tbrownaw wrote:
| > _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.
| commandlinefan wrote:
| "You need to commit to your due dates. But you also need to drop
| everything continuously to respond to critical issues."
| [deleted]
| gmfawcett wrote:
| 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 wrote:
| 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 wrote:
| Ah! I didn't read the image caption. You're right, it's
| explicitly Kanban. There goes my insightful HN comment!
| TameAntelope wrote:
| Due dates are a reflection of reality onto the world of software
| engineering.
|
| "We need a demoable product by <Convention>." is not "lazy".
| doctor_eval wrote:
| 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.
| IMTDb wrote:
| > Recognising this "reality", and building your software
| development processes around it, is _engineering_.
|
| A pillar of good engineering is understanding that the _when_
| and the _how much_ matter often as much as the _what_ and are
| fundamental inputs driving the _how_.
|
| Due dates are a key answer to one of the component, they also
| have the benefit of being crystal clear and unambiguous,
| something engineers should strive for. Software development
| is like gas: it will take precisely the space you give it
| (and probably leak a bit). Due dates are the simplest and
| most efficient way of constraining that space. The issue
| arise when they are unrealistic, or arbitrarily set, without
| being negotiated. But you absolutely need them.
|
| "A goal without a date is just a dream." - Milton H. Erickson
| tbrownaw wrote:
| I wouldn't call coordinating activities and balancing
| conflicting goals under partial information "easier" than
| just finding an excuse to punt on anything involving forward-
| looking statements.
| mym1990 wrote:
| 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 wrote:
| > 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.
| tessierashpool wrote:
| this is addressed in the blurb before the blog post even
| begins.
| [deleted]
| samatman wrote:
| 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.
| 0xbadcafebee wrote:
| 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 wrote:
| > 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.
___________________________________________________________________
(page generated 2022-04-13 23:01 UTC)