7 ms·

There are some very rare cases where delivery date is more important than what you are delivering, but modern management seems to delight in generalizing this u

There are some very rare cases where delivery date is more important than what you are delivering, but modern management seems to delight in generalizing this unusual occurrence to every situation. People do get promoted for having been able to deliver completely broken, useless and damaging solutions on time. If that’s the measure of project success you can expect dates to rule (even when they continuously slide). After all, if you are not a trained surgeon, and the only thing you are told is that a given surgery should last no more than X hours, guess what will be the one criterium for all your actions during the operation. I love that metaphor.

crocal 9y ago
Yeah but not all things are like surgery. Often, « A good violent attack now is better than a perfect one next week » (George S. Patton)
- qq66 9y ago
  And, plenty of surgeries are done in situations where speed matters more than the quality of the surgery (emergency tracheotomy, amputation, etc.)
  - dvt 9y ago
    Speed never matters more than the quality of the surgery. You're conflating constraints and criteria. Speed is sometimes a constraint, but never a criteria.
    - brucephillips 9y ago
      Constraints are criteria.
      - zbentley 9y ago
        No, they're not. If you violate a constraint, delivery fails. If you pass it, delivery does not necessarily succeed. If you fail to meet a criterion, delivery might fail. If you successfully meet all criteria, this is the definition of successful delivery. Different places may assign different meanings to those terms in project-management speak, but those are the ones I've heard the most.
        brucephillips 9y ago
        You're confusing an equality relationship and a subset relationship.
      - dvt 9y ago
        No they aren't. Constraints are necessary but not sufficient. Criteria are necessary and sufficient. In other words, necessity is a lower bound and sufficiency is an upper bound. Criteria is the upper bound, constraints are the lower bound. [1] https://www.sfu.ca/~swartz/conditions1.htm https://www.sfu.ca/~swartz/conditions1.htm
        brucephillips 9y ago
        You're also confusing an equality and a subset relationship.
    - stefco_ 9y ago
      But speed is a self-imposed constraint on most projects rather than a physical law, meaning it might be violated. Furthermore, there might be a smooth relationship between speed of execution and value returned (even outside of cost of production). So when evaluating how successful a project was (software, surgery, or otherwise), you often do want to use speed as a criterion, even if you initially thought of it as a sort of constraint for the sake of simplifying planning.
- junkscience2017 9y ago
  Patton's strategy was borrowed from his inspiration...Sherman. The goal was to make war intensely in order to end it quickly and let his soldiers return to their lives. Software development is not war.
  - CapitalistCartr 9y ago
    Business often is, though.
    - jschwartzi 9y ago
      Business never ends though. If you spend all your time making business intensely, you will burn everyone in your business out.
      - brucephillips 9y ago
        The metaphor extends further, actually. The "war" of business ends once a market consolidates.
  - scirocco 9y ago
    It is, if you ask Ben Horowitz
- lj3 9y ago
  That doesn't apply to software development unless you're a startup with limited funding and no positive cash flow. In the vast majority of cases, the software is already released and making money. Whether you finish the next release in 1 month or 2 is of no practical importance, except that it makes the manager look good. He can report a larger profit margin because the cost that went into that release is roughly half if it was released in 1 month rather than 2. And therein lies the conflict that this post doesn't really address or resolve: there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower. A great real world example of this is PUBG.
  - shandor 9y ago
    > there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower. A wonderful insight, thanks. I guess that hints in a direction where "both are Right". For the technical teams, it's self-explanatory that "one does not simply push out crap". On the other hand, the MBAs and finance hear engineering say the same thing about mostly everything, and double profit margin is double profit margin, so the incentive structures that encourage faster releases probably seem completely plausible to them. Not that things are that clear and clean in real life. But having drifted from pure engineering to engineering management during the years, I feel more and more sympathy towards some of the challenges of the "ugly and evil business side" by the year. Also, nothing is as hard as communication. Except trying to communicate goals with broad incentive structures, I guess.
  - brucephillips 9y ago
    > Whether you finish the next release in 1 month or 2 is of no practical importance, except that it makes the manager look good. No, it also increases value to the customer, and therefore price. It also helps you stay ahead of the competition, also increasing price. Can you elaborate on PUBG?
    - lj3 9y ago
      > it also increases value to the customer, and therefore price Not always. Look at the most recent OS releases. Windows 8 and 10 had terrible adoption rates because they actually deliver a negative value for most users compared to what they already own (windows 7). > It also helps you stay ahead of the competition, also increasing price. Again, not always, for the same reasons mentioned above. > Can you elaborate on PUBG? From a technical point of view, PUBG is a train wreck. They had budgeted a 1 year development cycle, which for an online 3d FPS is ridiculously short. I think they initially launched it after a year and a half of development. But, from a sales point of view, PUBG has been very profitable. People are playing it despite the networking problems and relatively bad graphics because it fills a niche that hasn't been addressed by other game companies in years. But, there was no guarantee it would have been a hit. The condensed timeline and less than stellar graphics was their way of keeping development costs low. If the game hadn't been an instant hit, they could have still made a profit.
- sebcat 9y ago
  "It is even better to act quickly and err than to hesitate until the time of action is past" -- Carl von Clausewitz (On War?)
euroclydon 9y ago
Where I work, we deliver on time. Customers schedule upgrades many months in advance, and in series or sync with other upgrades. They are on maintenance contracts to get the latest version. If we deliver a broken product, than that is a failure to cut scope adequately. Do that once or twice and suffer through the consequences and you will learn not to let it happen again.
- jjoonathan 9y ago
  Moving a feature into the next release cycle is equivalent to extending the deadline for that feature. You're right, though -- management does seem to have a strong preference for one terminology over the other.
  - euroclydon 9y ago
    That’s true, but if the product is big enough, with enough varying constituencies, then delivering something to a large chunk of those people on time is a lot better than delivering nothing to everybody on time.
    - tfigment 9y ago
      I think there is a lot of "it depends" in here. If deployment is zero friction to the customer then maybe this applies. If deployment by customer is disrupting then forcing them to go through multiple release cycles due to bugs or lack of required features can be worse for them. I just lived with a half-broken product for a year rather than deploy the more final full featured but less stable version multiple times from a vendor due to such deployment difficulty. I want quality and completeness over speed in that case.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
mbesto 9y ago
FYI - They use the same metaphor in Mythical Man Month and it's very apt.
tyingq 9y ago
Deadlines do matter in many situations. Like, for example, being able to announce a new product or feature at a conference with a fixed date. Or before a sales meeting with a new client, or before a yearly allocated budget expires, etc. I have, however, also encountered arbitrary deadlines that people hang onto for no good reason.

crocal 9y ago

Yeah but not all things are like surgery. Often, « A good violent attack now is better than a perfect one next week » (George S. Patton)

qq66 9y ago
And, plenty of surgeries are done in situations where speed matters more than the quality of the surgery (emergency tracheotomy, amputation, etc.)
- dvt 9y ago
  Speed never matters more than the quality of the surgery. You're conflating constraints and criteria. Speed is sometimes a constraint, but never a criteria.
  - brucephillips 9y ago
    Constraints are criteria.
    - zbentley 9y ago
      No, they're not. If you violate a constraint, delivery fails. If you pass it, delivery does not necessarily succeed. If you fail to meet a criterion, delivery might fail. If you successfully meet all criteria, this is the definition of successful delivery. Different places may assign different meanings to those terms in project-management speak, but those are the ones I've heard the most.
      - brucephillips 9y ago
        You're confusing an equality relationship and a subset relationship.
    - dvt 9y ago
      No they aren't. Constraints are necessary but not sufficient. Criteria are necessary and sufficient. In other words, necessity is a lower bound and sufficiency is an upper bound. Criteria is the upper bound, constraints are the lower bound. [1] https://www.sfu.ca/~swartz/conditions1.htm https://www.sfu.ca/~swartz/conditions1.htm
      - brucephillips 9y ago
        You're also confusing an equality and a subset relationship.
  - stefco_ 9y ago
    But speed is a self-imposed constraint on most projects rather than a physical law, meaning it might be violated. Furthermore, there might be a smooth relationship between speed of execution and value returned (even outside of cost of production). So when evaluating how successful a project was (software, surgery, or otherwise), you often do want to use speed as a criterion, even if you initially thought of it as a sort of constraint for the sake of simplifying planning.
junkscience2017 9y ago
Patton's strategy was borrowed from his inspiration...Sherman. The goal was to make war intensely in order to end it quickly and let his soldiers return to their lives. Software development is not war.
- CapitalistCartr 9y ago
  Business often is, though.
  - jschwartzi 9y ago
    Business never ends though. If you spend all your time making business intensely, you will burn everyone in your business out.
    - brucephillips 9y ago
      The metaphor extends further, actually. The "war" of business ends once a market consolidates.
- scirocco 9y ago
  It is, if you ask Ben Horowitz
lj3 9y ago
That doesn't apply to software development unless you're a startup with limited funding and no positive cash flow. In the vast majority of cases, the software is already released and making money. Whether you finish the next release in 1 month or 2 is of no practical importance, except that it makes the manager look good. He can report a larger profit margin because the cost that went into that release is roughly half if it was released in 1 month rather than 2. And therein lies the conflict that this post doesn't really address or resolve: there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower. A great real world example of this is PUBG.
- shandor 9y ago
  > there's rarely a discernible difference in revenue between a high quality release and a buggy, low quality release, but the profit margin of the former can be (and often is) much lower. A wonderful insight, thanks. I guess that hints in a direction where "both are Right". For the technical teams, it's self-explanatory that "one does not simply push out crap". On the other hand, the MBAs and finance hear engineering say the same thing about mostly everything, and double profit margin is double profit margin, so the incentive structures that encourage faster releases probably seem completely plausible to them. Not that things are that clear and clean in real life. But having drifted from pure engineering to engineering management during the years, I feel more and more sympathy towards some of the challenges of the "ugly and evil business side" by the year. Also, nothing is as hard as communication. Except trying to communicate goals with broad incentive structures, I guess.
- brucephillips 9y ago
  > Whether you finish the next release in 1 month or 2 is of no practical importance, except that it makes the manager look good. No, it also increases value to the customer, and therefore price. It also helps you stay ahead of the competition, also increasing price. Can you elaborate on PUBG?
  - lj3 9y ago
    > it also increases value to the customer, and therefore price Not always. Look at the most recent OS releases. Windows 8 and 10 had terrible adoption rates because they actually deliver a negative value for most users compared to what they already own (windows 7). > It also helps you stay ahead of the competition, also increasing price. Again, not always, for the same reasons mentioned above. > Can you elaborate on PUBG? From a technical point of view, PUBG is a train wreck. They had budgeted a 1 year development cycle, which for an online 3d FPS is ridiculously short. I think they initially launched it after a year and a half of development. But, from a sales point of view, PUBG has been very profitable. People are playing it despite the networking problems and relatively bad graphics because it fills a niche that hasn't been addressed by other game companies in years. But, there was no guarantee it would have been a hit. The condensed timeline and less than stellar graphics was their way of keeping development costs low. If the game hadn't been an instant hit, they could have still made a profit.
sebcat 9y ago
"It is even better to act quickly and err than to hesitate until the time of action is past" -- Carl von Clausewitz (On War?)

euroclydon 9y ago

Where I work, we deliver on time. Customers schedule upgrades many months in advance, and in series or sync with other upgrades. They are on maintenance contracts to get the latest version. If we deliver a broken product, than that is a failure to cut scope adequately. Do that once or twice and suffer through the consequences and you will learn not to let it happen again.

jjoonathan 9y ago
Moving a feature into the next release cycle is equivalent to extending the deadline for that feature. You're right, though -- management does seem to have a strong preference for one terminology over the other.
- euroclydon 9y ago
  That’s true, but if the product is big enough, with enough varying constituencies, then delivering something to a large chunk of those people on time is a lot better than delivering nothing to everybody on time.
  - tfigment 9y ago
    I think there is a lot of "it depends" in here. If deployment is zero friction to the customer then maybe this applies. If deployment by customer is disrupting then forcing them to go through multiple release cycles due to bugs or lack of required features can be worse for them. I just lived with a half-broken product for a year rather than deploy the more final full featured but less stable version multiple times from a vendor due to such deployment difficulty. I want quality and completeness over speed in that case.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]

mbesto 9y ago

FYI - They use the same metaphor in Mythical Man Month and it's very apt.

tyingq 9y ago

Deadlines do matter in many situations. Like, for example, being able to announce a new product or feature at a conference with a fixed date. Or before a sales meeting with a new client, or before a yearly allocated budget expires, etc. I have, however, also encountered arbitrary deadlines that people hang onto for no good reason.