Due dates are a lazy way to gain commitment | Hacker News Reader

Due dates are a lazy way to gain commitment

tristanhood.substack.com

68 pointsrmason52 comments

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

dance for that paycheck, human

s/human/victim of capitalism

Alternatives to capitalism don't have a great track record with quotas either. We're just victims of poor management.

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.

> 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.

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

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."

> 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.

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!

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.

From the perspective of an engineer who cares about nothing but getting paid, the whole discussion in the OP is irrelevant, no? the whole thing is about somebody else's problems irrelevant to you, you'll get paid and probably not fired with or without irrelevant due dates.

Or it tears your ego apart because you are a young developer that has never shipped anything. Reminds me of my first job.

> 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

But that wasn't known. They expected to need it, and when circumstances changed, they canceled the project. It seems to have been a huge project; "don't start work on the project until you need it to be finished" was never going to work.

You can't judge people by what they should have done if they'd had perfect knowledge of the future. If anyone involved had had perfect knowledge of the future, they wouldn't have been working for the company anyway.

Who said anything about judging people?

You did, when you described something as "wrong".

I did, before you, when I did the same thing, but it's not like you disagreed with the premise.

I think there's something wrong with it in the sense that it would be preferable to do differently and worth thinking about if there's a way to do better. I don't associate that with judging anyone.

> "Oh, don't worry about it then, we just won't be first to market."

Supposedly there's a thing called "first-mover advantage". Making the deadline would get them $XXX, and missing it only gets $XX but is still worth doing.

There's a way to map an additional X% chance of making the deadline to being worth some dollar amount of extra effort. Ideally done with full knowledge that it is somewhat of a gamble, and that the dev team don't need to catch any frustration if it doesn't work out.

> "Looks like we won't be using that system anymore, so we can sunset the replacement."

Makes sense to be. Replacing the system would have benefits worth an estimated $X/year, but it takes long enough that the world changed under you and it no longer matters.

> 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."

I'm not sure how many execs would be totally chill with not being first to market if they could have been, but I have seen "Oh, that's actually okay, we been saying March knowing it'd really be September. So you have more time, but it really has to be September"

And then the exec pats themselves on the back for their smart planning, while the engineers regret all the corners that they wouldn't have cut if they'd known they had more time.

True - but you're forgetting the executives previously learned experience of telling a team that a due date was September and them delivering six months later. The consequence was missing the marketing/PR window, negatively impacting the future valuation of the company, reducing sales and leading the board to fire the executive.

... most people aren't arbitrary, they have different experiences or perspectives which leads them to 'rational' decisions.

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.

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?

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.

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.)

Due dates are a reflection of reality onto the world of software engineering.

"We need a demoable product by <Convention>." is not "lazy".

this is addressed in the blurb before the blog post even begins.

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.

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.

> 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.

Wow, getting a manager re-assigned because you didn't like how the project was being managed, real flex there.

"I've"..."my"..."I"..."I"...do you see a pattern?

> I've worked successfully for the last few decades of my career

A pattern of success?

Nope, a gold star to you for trying though.

But a due date is the opposite of working together and being flexible. A due date is more often than not imposed on a team because of some fable about how some other team, but especially sales, needs to hook this big deal. And in my long experience, sales is never, ever ready - even if you bust your gut to meet the deadline.

I am surely not the only one here to have finished a death march only to have sales tell me they don’t need it any more. That’s not working together, that’s just putting product and engineering at the bottom of the hierarchy.

The fact is that any non trivial project has many so-called “unknown unknowns” and these needs to be part of the process, or the project will either fail, or cause significant stress, all of which results in poor outcomes for everyone.

I don’t understand why it is so hard to imagine honest collaboration. Due dates are not a magic bullet, and just because you set a date doesn’t mean it gets done then. We know this because it’s generally more surprising when a team ships on time, than when they don’t. A product simply can’t be shipped until it’s done, and no due date will change that.

Because of this, due dates are simply a bludgeon used to bash over the heads of the people doing the work. They result in high levels of stress, corner cutting, and poor outcomes for everyone, including the business.

There are a ton of ways that you can have meaningful collaboration within and between teams without imposing artificial, top-down deadlines which are of necessity created using imperfect information, and then imposed on the team as law.

One of which is to have a well defined strategy, clear goals, honest collaboration, and delayed decision making. But that requires managers to actually think about and be able to express what they’re doing and why; a set of skills that I’ve found to be in short supply.

Magical thinking can be that strong in business-side people (executives, managers, PMs, etc.) They are used to exerting their will on others and not being pushed back on.

OMG yes. I am so triggered by this thread that I need to take a chill pill.

> 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

You can’t pin down the when, how much, what and how all at the same time. Like the old adage says, “better, faster, cheaper” - choose two. Most teams have a fixed set of resources, and therefore a fixed cost. So, if you set a deadline then you’re setting quality as the variable.

Low quality software generally fails to achieve the business goals either because it results in poor customer satisfaction or low reliability, leading to high OPEX.

Like most things in life, there is a trade off to be made, and setting some magical “due date” is just a lazy way to manage a team. In my experience it’s a blunt instrument used by people who don’t know how to build good software.

> "A goal without a date is just a dream." - Milton H. Erickson

Milton Hyland Erickson was an American psychiatrist and psychologist specializing in medical hypnosis and family therapy. [0]. Clearly a guy who knew all about dreams, but nothing about software engineering.

[0] https://en.wikipedia.org/wiki/Milton_H._Erickson

> You can’t pin down the when, how much, what and how all at the same time

Precisely. And my point is that you should set the when and how much as soon as possible. Then negotiate the what. Then, based on all these information, decide on the how.

Usually tho, people love to start on the what, immediately think about the how, and give pointer on the how much. Inevitably, the when question comes, and can significantly alter the other points. Everyone hates to have their "perfect plan" questioned by an external deadline, and management is resented for it.

As engineers, the how is where we have the most control and knowledge, so this should serve as an adjustment variable, not the other way around.

The Milton quote applies really well to software engineering, we have all known tons of projects that linger in the "80% done" state for extended periods of time, it's a staple of engineering. A significant portion of project management is psychology. Some of the best PM I have had had almost 0 technical background.

I guess we really just differ in that I don't think the "when" is necessarily the most important thing. It's just as much a part of the negotiation as the what, how etc; it's just one dimension of many. It's often, but not always, the key driver.

But you don't seem to be the kind of lazy manager that this article talks about. If you're OK to say that the date is the most important thing, and we understand that this might mean we have to sacrifice features or quality or whatever, then that's perfectly reasonable. It's an explicit trade off that you can communicate clearly to your team.

But all too often, we're told that we need to have N features in T time, and when it's delivered half assed and full of bugs, well that's our fault.

And I think that's the essence of lazy management, because it's really just trying achieve success through the force of will, which IME doesn't work very often.

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.

There is a big difference between working together to achieve some desirable outcome, versus setting some artificial deadline and using it to hit people over the head when they don’t reach it.

I’ve worked on far too many projects where a deadline has been set, and me and my team have busted our asses - and sometimes been forced to cut a bunch of corners - only for the rest of the project to drop the ball.

That’s why due dates are lazy. It’s much easier for a manager to say “do it in 8 weeks” than it is for them to communicate strategy, set intermediate goals, monitor progress, and adapt to change.

Thinking that you're building software "for the love of the game" instead of, "to make money" is a common mistake engineers make. Don't make that mistake.

You're responding to an example of a very not arbitrary deadline, such as what happens in markets on a fairly regular basis, upon which there is very often money to be made.

That’s not remotely what I said. Of course getting a product done is important. Of course specific dates are sometimes important. But that doesn’t mean that due dates aren’t a lazy and inefficient management tool. In fact, I’d say it’s especially true if you have a non movable deadline. That’s when you need the absolute greatest flexibility and communication.

But due dates didn’t get me where I am today - which is a pretty happy place - despite how much I tried. What worked was honest and clear communication with my teams, explicit goal setting, a clear strategy, frequent review, and trust in my team to work hard and do a great job.

Every single time I’ve been forced by so-called managers to spend my time setting arbitrary dates rather than focusing on my goals and managing my teams, the project has failed spectacularly. You wouldn’t believe some of the crap I’ve seen, and I’m pretty sure I’m not alone.

Software development is the reification of the halting problem. It’s quite literally impossible to know how long it will take to build a set of non trivial features without actually building them - yet here we are talking about how we should do that anyway.

Due dates are not a lazy an inefficient management tool, lazy and inefficient due dates are.

Due dates are tools, they are not moralizations. Your bad experience with a tool does not mean the tool is broken, just that you used it incorrectly.

You honestly seem to have a beef with the term "due dates", which is completely irrational. They can be good, they can be bad, but they are not inherently lazy or inefficient, they're a reflection of the undeniable reality that your work must produce value, and sometimes that value is time sensitive.

You can strawman the concept all day, your definition of "due dates" does not reflect the reality of what they are.

You are welcome to reflect on your own experience, but you can’t tell me mine. I’ve watched projects burn to the ground because of crappy, deadline driven management that refused to accept the realities of software development.

Maybe you’ve worked for managers for whom due dates were implemented in an intelligent and respectful way, but sadly that’s not been my experience over the past 30 years.

I didn’t tell you your experience, I interpreted your experience. You don’t have a monopoly on truth just because you experienced something.

You could have 100 years of experience, it would still not make your observations statistically significant, even if they were objective, which they aren’t.

You said it yourself; you had crappy managers. It stands to reason anything they would have done would be bad. Due dates weren’t your problem, bad management was.

This is a thread on an article entitled “Due dates are a lazy way to gain commitment”. We obviously don’t agree here, and that’s fine. Let’s leave it at that.

This is a thread on a comment where I explain how the article is not accurate, it’s not just that we disagree, it’s that you’re not acting in concert with reality.

I do not intend to leave anything “at that”, simply because you don’t like how the conversation is going. Someone else is free to reply.

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.

>“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".

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.

> 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.

Plans change, but planning is essential.

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

Reply on news.ycombinator.com