8 ms·

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)

by crocal 9y ago

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

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)

by 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?)