7 ms·

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.
    - mym1990 5y ago
      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?
      - doctor_eval 5y ago
        > I've worked successfully for the last few decades of my career A pattern of success?
        mym1990 5y ago
        Nope, a gold star to you for trying though.
  - doctor_eval 5y ago
    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 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 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.
    - nathanaldensr 5y ago
      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.
      - doctor_eval 5y ago
        OMG yes. I am so triggered by this thread that I need to take a chill pill.
- IMTDb 5y ago
  > 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
  - doctor_eval 5y ago
    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 https://en.wikipedia.org/wiki/Milton_H._Erickson
    - IMTDb 5y ago
      > 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.
- tbrownaw 5y ago
  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.
  - doctor_eval 5y ago
    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.
- deleted 5y ago
  [deleted]
- TameAntelope 5y ago
  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.
  - doctor_eval 5y ago
    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.
    - TameAntelope 5y ago
      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.

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.
  - mym1990 5y ago
    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?
    - doctor_eval 5y ago
      > I've worked successfully for the last few decades of my career A pattern of success?
      - mym1990 5y ago
        Nope, a gold star to you for trying though.
- doctor_eval 5y ago
  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 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 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.
  - nathanaldensr 5y ago
    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.
    - doctor_eval 5y ago
      OMG yes. I am so triggered by this thread that I need to take a chill pill.
IMTDb 5y ago
> 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
- doctor_eval 5y ago
  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 https://en.wikipedia.org/wiki/Milton_H._Erickson
  - IMTDb 5y ago
    > 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.
tbrownaw 5y ago
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.
- doctor_eval 5y ago
  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.
deleted 5y ago
[deleted]
TameAntelope 5y ago
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.
- doctor_eval 5y ago
  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.
  - TameAntelope 5y ago
    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.