5 ms·

I agree with you on bullshit dates. But I don't think this part is true: > Regardless of what you think your process is, somewhere near the top of the leadersh

I agree with you on bullshit dates. But I don't think this part is true: > Regardless of what you think your process is, somewhere near the top of the leadership pyramid, it all boils down to a customer promise upon which hinges your organization's reputation. First, I see the same sort of dysfunctions driven by The Date™ even when no customer promise is involved. Even when no customers are involved. Second, if honoring customer promises were the number one priority, organizations wouldn't make them so casually and without figuring out what is possible. Third, they would use management approaches that make it maximally likely to really hit customer promises, not just in terms of date but features and quality. If I have a date that really matters, I'll aim for first MVP by 50% of the schedule. Then we use customer feedback to iteratively improve every week, so at the deadline we have something polished and proven to satisfy. Fourth, they'd try to hit dates in ways that build capacity to make good on future promises. Instead, the panics I see around The Date™ mean technical debt, strained processes, and burnt-out staff, all of which diminish odds of satisfying promises in the future.

Clubber 5y ago
>Second, if honoring customer promises were the number one priority, organizations wouldn't make them so casually and without figuring out what is possible. I can't tell you how many times I asked, "who came up with this deadline?" and I get "someone in the sales team," or something like that.
- long_time_gone 5y ago
  The sales team works closest with people who will become customers, it’s not crazy for them to be plugged into a customers needs or priorities. That said, lots of sales people make promises first and figure out the details later which isn’t good business.
  - wpietri 5y ago
    For sure. Any good product balances desire and possibility. Salespeople have a lot of data on desire; engineers on possibility. The problem isn't involving sales. It's not involving the engineers!
    - regularfry 5y ago
      Heavily sales-promise-driven product development is also bad for the company long-term. Saying yes to everything (for even small values of "everything") creates products that are just feature swamps, and not especially compelling at any one thing.
      - Closi 5y ago
        Depends on the company and sector - companies that aren’t flexible enough during the sales process fail to win business (particularly on the enterprise side) so there is clearly a trade off here.
- willcipriano 5y ago
  You are flying a plane over the Atlantic and you realize that you may not have enough fuel to make it to shore. Your options are: 1. Focus on flying the plane in a manner that uses as little fuel as possible not bothering to even glace at the fuel gauge, watching the air currents and gliding where possible. 2. Turn on autopilot and spend time and effort trying to calculate the fuel you have to see if you make it to shore before going back to flying as conservatively as possible. Number 2 feels better. Number 1 is more likely to end with a safe landing. If you have a deadline and won't be getting new resources any time soon, and what purpose does a estimate serve if you are already committed?
  - Gravityloss 5y ago
    You could make a compromise. If you have a rough idea where you'll ditch, you can radio that to air traffic control and ships can be sent ahead of time so that when / if the ditching happens, they can to try to rescue people. Ships can act as bases for helicopters as well.
    - willcipriano 5y ago
      What would the business version of that be? Update your Linkedin, do some LeetCode?
      - Gravityloss 5y ago
        In business, life goes on even if the project is late, there just has to be some accommodations. It's less painful the earlier it is known.
  - afarrell 5y ago
    You’ve just made an analogy to a situation that ~never happens in complex profession which ~none of us have direct experience in at a professional level. Thats fine, but it doesn’t really help with reasoning. An estimate serves the purpose of allowing you to say “well the deadline is in 3 weeks and our best estimate is that this will take 9 weeks. Lets save ourselves the effort, cancel the project, and do something more profitable with our time. In your analogy, that would be the equivalent of… jumping out of the airplane mid-flight, confident that you can just ride brooms to Iceland because thinking of this as a life-or-death decision is incorrect.
FourthProtocol 5y ago
First, there's always a customer, and so there is always a promise, and always a customer. Customer can mean you, your boss, an external client, the general public, the janitor who's keycard doesn't work on the ladies bathroom at 2am when no project managers, business line owners or even ladies are around to watch him clean. Second, profitability is usually the number one priority. Third, they DO use management approaches that make it maximally likely... ...that they achieve profitability. Fourth yes, they would and they do. Unfortunately most don't understand that it is impossible to estimate a fixed period of time in which an unknown problem can be solved. This always comes full circle to Steve McConnell's book Software Estimation. In my 34 years in IT, across three continents, in industry sectors ranging from insurance and telecoms to aerospace and defencee, and Nokia Maps, that book will take you closer to the grail than anything else on earth. And you'll still remain light years from an accurate estimate until the day you ship.
- wpietri 5y ago
  That first one is stretching the definition of "customer" quite vigorously. Certainly beyond the bounds of the post I was replying to. A company's reputation does not hinge on whether the janitor's keycard works on the ladies' bathroom at 2am by a made-up date. Long-term profit is not the number-one actual priority of American management methods. Not even close. As an example, look at Toyota versus the big 3 American car manufacturers. Toyota is much more profitable [1] and has been for decades. That's because for Toyota profit is an outcome, not a holy grail. The actual priority of American management methods is making executives look/feel smart, in control, and dominant so they can justify extracting lots of cash. I do agree that they use management techniques likely to achieve those feelings. And that includes making up bullshit dates and then insisting everybody make them happen. But that's part of the problem. [1] https://www.detroitnews.com/story/business/autos/2015/02/22/toyota-per-car-profits-beat-ford-gm-chrysler/23852189/ https://www.detroitnews.com/story/business/autos/2015/02/22/...
  - darkerside 5y ago
    Toyota is still pursuing profit. They are just operating within a larger scope of time. Profitable this quarter vs this year vs this decade are all very different goals. Edit: And that definition of customer is not uncommon in the industry. It helps to know who your customer is.
jrochkind1 5y ago
> First, I see the same sort of dysfunctions driven by The Date™ even when no customer promise is involved. Even when no customers are involved. I believe it, but I've also seen the reverse too. In a situation where no customers are involved, at a non-profit enterprise. When we have a launch date, it helps provide focus on distinguishing what's truly necessary from what's not, and using our development resources responsibly. The launch date needs to be reasonable, and it needs to be understood that it can slip (especially if new requirements show up), but it provided a lot of focus. Having no launch date, sometimes everything but the kitchen sink ends up being thrown in, anything that anyone ever thought was a good idea, and we lose focus on the mission or the end-user, and the project can stretch on forever never being done.
- regularfry 5y ago
  But this is what (for instance) Scrum and XP should give you. The Date is two weeks from now. What do we intend to ship? Did we do that? Shall we do it again? We've got another The Date in two weeks. What do we intend to ship? Repeat until everyone gets acquihired and vanishes into the bowels of AmaMetaFlixgle.
  - wpietri 5y ago
    Exactly. Releasing early and often to an ever-widening circle of stakeholders provides the same discipline with much less pathology.
  - jrochkind1 5y ago
    Sure, that's the intent. I trust we don't need to reiterate all the ways it can go wrong, with a management culture that is dysfunctional. (Really, so much of software engineering methodology can be understood as "how do we compensate for dysfunctional management culture, or, at best, what practices can help and support our management to learn to be more functional.") In some cases, especially in the "enterprise", it's literally not possible to have something you can actually deploy in production (not just a proof-of-concept demo) after a single two-week sprint. In some cases, you only get so many chances to get press and public attention for something, and have to decide at what point it's going to be sufficiently impressive to do so. I agree that focusing on getting something live as soon as possible is a good idea, in almost all circumstances. There may be some stakeholders whose idea of "as soon as possible" is not as soon as yours. In some cases stakeholders deciding "shall we do it again" are basically always going to say "yes", until someone says "enough" and sets a date at which it will be cut off -- which then forces management to be really serious about figuring out the most important thing to go in every sprint until then. It is always very important to realize "you can have a fixed date OR a fixed feature/requirements set, not both." In some cases, the focus of a fixed date and "now what's really important to get in there if we can't get everything in" is more useful than a fixed feature set "and let's see how long it takes" stretching on forever with diminishing returns and nobody saying "you know, actually, it would be more valuable to the organization to work on something else now?" In my experience, working in certain kinds of organizations!
jimmySixDOF 5y ago
Unfortunately development does not exist in a vacuum. The Date(TM) can have a slew of dependencies that chain react down the line. Perhaps your client's training was booked months in advance with flights and stand-in schedules all based all on some dev feature being available in class. Or hard to reschedule subcontractors were booked six months ago for Pen-Testing and The Date(TM) is slipping. Things like this have costs and consequences beyond technical software debt and in many cases come with enforceable penalty clauses which you don't want to trigger. Yes, there is always a tension between the hands down best guess of what was possible when you made the commitment vs the actual critical path as revealed by experience over time, but you live with those unknown risks and degrees of certainty and proceed. You Meet The Date(TM). I also think Radical Transparency plays a role here that was lost on the 'successful' PM referenced in GP's story. If you cancel weekends and duct tape together things you need to fix later to meet a date then everyone involved should be 100% clear on why it is so important. And agree. There is a reason some activities are called Sprints. You can't do them all the time. A Sprint is a defined burst of energy- maximally applied. Anything else is a different kind of race. Business as Usual, is a marathon for instance. But, occasionally, you need to produce a Sprint to Meet The Date (TM). Point is that the GP's PM-in-question might have accomplished more with better honesty relationships including a well thought out & generous TOIL [1] program that could compensate for the off chance that some institutional shortsightedness at an earlier planning stage- where commitments were made that may have seemed like a good idea at the time- proved more difficult than anticipated and resulted in a need for Sprints. [1] https://citrushr.com/blog/leave-absence/what-is-toil-and-how-does-it-work/ https://citrushr.com/blog/leave-absence/what-is-toil-and-how...
- wpietri 5y ago
  I agree that The Date™ is sometimes driven by legitimate factors. And that other things often become tied on to The Date™. But The Date™ also is a BFD when none of that is true. And if things like client training and penalty clauses were all that important, people would be extremely careful about picking dates that are realistic. Instead, frequently The Date™ is made up and people get fetishistic about Meeting The Date™ in ways that are untethered from actual circumstances or consequences. That's a sign to me that the real purpose of The Date™ is not the nominal purpose. > There is a reason some activities are called Sprints. You can't do them all the time. This is a perfect example of how distinct the nominal purpose and the actual behaviors are. In the Scrum framework, things are structured as an unending series of Sprints, back to back from here to eternity. Whereas in reality, a sprinter like Usain Bolt runs, what, 10 or 20 officially timed races per year at under a minute each? And the rest of the time recovering, prepping, and training.
darkerside 5y ago
Organizations make promises to close deals. Customers usually don't care how long it takes as much as they care about when they need it. There is variability in the bandwidth of those constraints (and in price paid) which is why we have a sales process. At the end of that process, making changes is really hard. So here we are.

Clubber 5y ago

>Second, if honoring customer promises were the number one priority, organizations wouldn't make them so casually and without figuring out what is possible. I can't tell you how many times I asked, "who came up with this deadline?" and I get "someone in the sales team," or something like that.

long_time_gone 5y ago
The sales team works closest with people who will become customers, it’s not crazy for them to be plugged into a customers needs or priorities. That said, lots of sales people make promises first and figure out the details later which isn’t good business.
- wpietri 5y ago
  For sure. Any good product balances desire and possibility. Salespeople have a lot of data on desire; engineers on possibility. The problem isn't involving sales. It's not involving the engineers!
  - regularfry 5y ago
    Heavily sales-promise-driven product development is also bad for the company long-term. Saying yes to everything (for even small values of "everything") creates products that are just feature swamps, and not especially compelling at any one thing.
    - Closi 5y ago
      Depends on the company and sector - companies that aren’t flexible enough during the sales process fail to win business (particularly on the enterprise side) so there is clearly a trade off here.
willcipriano 5y ago
You are flying a plane over the Atlantic and you realize that you may not have enough fuel to make it to shore. Your options are: 1. Focus on flying the plane in a manner that uses as little fuel as possible not bothering to even glace at the fuel gauge, watching the air currents and gliding where possible. 2. Turn on autopilot and spend time and effort trying to calculate the fuel you have to see if you make it to shore before going back to flying as conservatively as possible. Number 2 feels better. Number 1 is more likely to end with a safe landing. If you have a deadline and won't be getting new resources any time soon, and what purpose does a estimate serve if you are already committed?
- Gravityloss 5y ago
  You could make a compromise. If you have a rough idea where you'll ditch, you can radio that to air traffic control and ships can be sent ahead of time so that when / if the ditching happens, they can to try to rescue people. Ships can act as bases for helicopters as well.
  - willcipriano 5y ago
    What would the business version of that be? Update your Linkedin, do some LeetCode?
    - Gravityloss 5y ago
      In business, life goes on even if the project is late, there just has to be some accommodations. It's less painful the earlier it is known.
- afarrell 5y ago
  You’ve just made an analogy to a situation that ~never happens in complex profession which ~none of us have direct experience in at a professional level. Thats fine, but it doesn’t really help with reasoning. An estimate serves the purpose of allowing you to say “well the deadline is in 3 weeks and our best estimate is that this will take 9 weeks. Lets save ourselves the effort, cancel the project, and do something more profitable with our time. In your analogy, that would be the equivalent of… jumping out of the airplane mid-flight, confident that you can just ride brooms to Iceland because thinking of this as a life-or-death decision is incorrect.

FourthProtocol 5y ago

First, there's always a customer, and so there is always a promise, and always a customer. Customer can mean you, your boss, an external client, the general public, the janitor who's keycard doesn't work on the ladies bathroom at 2am when no project managers, business line owners or even ladies are around to watch him clean. Second, profitability is usually the number one priority. Third, they DO use management approaches that make it maximally likely... ...that they achieve profitability. Fourth yes, they would and they do. Unfortunately most don't understand that it is impossible to estimate a fixed period of time in which an unknown problem can be solved. This always comes full circle to Steve McConnell's book Software Estimation. In my 34 years in IT, across three continents, in industry sectors ranging from insurance and telecoms to aerospace and defencee, and Nokia Maps, that book will take you closer to the grail than anything else on earth. And you'll still remain light years from an accurate estimate until the day you ship.

wpietri 5y ago
That first one is stretching the definition of "customer" quite vigorously. Certainly beyond the bounds of the post I was replying to. A company's reputation does not hinge on whether the janitor's keycard works on the ladies' bathroom at 2am by a made-up date. Long-term profit is not the number-one actual priority of American management methods. Not even close. As an example, look at Toyota versus the big 3 American car manufacturers. Toyota is much more profitable [1] and has been for decades. That's because for Toyota profit is an outcome, not a holy grail. The actual priority of American management methods is making executives look/feel smart, in control, and dominant so they can justify extracting lots of cash. I do agree that they use management techniques likely to achieve those feelings. And that includes making up bullshit dates and then insisting everybody make them happen. But that's part of the problem. [1] https://www.detroitnews.com/story/business/autos/2015/02/22/toyota-per-car-profits-beat-ford-gm-chrysler/23852189/ https://www.detroitnews.com/story/business/autos/2015/02/22/...
- darkerside 5y ago
  Toyota is still pursuing profit. They are just operating within a larger scope of time. Profitable this quarter vs this year vs this decade are all very different goals. Edit: And that definition of customer is not uncommon in the industry. It helps to know who your customer is.

jrochkind1 5y ago

> First, I see the same sort of dysfunctions driven by The Date™ even when no customer promise is involved. Even when no customers are involved. I believe it, but I've also seen the reverse too. In a situation where no customers are involved, at a non-profit enterprise. When we have a launch date, it helps provide focus on distinguishing what's truly necessary from what's not, and using our development resources responsibly. The launch date needs to be reasonable, and it needs to be understood that it can slip (especially if new requirements show up), but it provided a lot of focus. Having no launch date, sometimes everything but the kitchen sink ends up being thrown in, anything that anyone ever thought was a good idea, and we lose focus on the mission or the end-user, and the project can stretch on forever never being done.

regularfry 5y ago
But this is what (for instance) Scrum and XP should give you. The Date is two weeks from now. What do we intend to ship? Did we do that? Shall we do it again? We've got another The Date in two weeks. What do we intend to ship? Repeat until everyone gets acquihired and vanishes into the bowels of AmaMetaFlixgle.
- wpietri 5y ago
  Exactly. Releasing early and often to an ever-widening circle of stakeholders provides the same discipline with much less pathology.
- jrochkind1 5y ago
  Sure, that's the intent. I trust we don't need to reiterate all the ways it can go wrong, with a management culture that is dysfunctional. (Really, so much of software engineering methodology can be understood as "how do we compensate for dysfunctional management culture, or, at best, what practices can help and support our management to learn to be more functional.") In some cases, especially in the "enterprise", it's literally not possible to have something you can actually deploy in production (not just a proof-of-concept demo) after a single two-week sprint. In some cases, you only get so many chances to get press and public attention for something, and have to decide at what point it's going to be sufficiently impressive to do so. I agree that focusing on getting something live as soon as possible is a good idea, in almost all circumstances. There may be some stakeholders whose idea of "as soon as possible" is not as soon as yours. In some cases stakeholders deciding "shall we do it again" are basically always going to say "yes", until someone says "enough" and sets a date at which it will be cut off -- which then forces management to be really serious about figuring out the most important thing to go in every sprint until then. It is always very important to realize "you can have a fixed date OR a fixed feature/requirements set, not both." In some cases, the focus of a fixed date and "now what's really important to get in there if we can't get everything in" is more useful than a fixed feature set "and let's see how long it takes" stretching on forever with diminishing returns and nobody saying "you know, actually, it would be more valuable to the organization to work on something else now?" In my experience, working in certain kinds of organizations!

jimmySixDOF 5y ago

Unfortunately development does not exist in a vacuum. The Date(TM) can have a slew of dependencies that chain react down the line. Perhaps your client's training was booked months in advance with flights and stand-in schedules all based all on some dev feature being available in class. Or hard to reschedule subcontractors were booked six months ago for Pen-Testing and The Date(TM) is slipping. Things like this have costs and consequences beyond technical software debt and in many cases come with enforceable penalty clauses which you don't want to trigger. Yes, there is always a tension between the hands down best guess of what was possible when you made the commitment vs the actual critical path as revealed by experience over time, but you live with those unknown risks and degrees of certainty and proceed. You Meet The Date(TM). I also think Radical Transparency plays a role here that was lost on the 'successful' PM referenced in GP's story. If you cancel weekends and duct tape together things you need to fix later to meet a date then everyone involved should be 100% clear on why it is so important. And agree. There is a reason some activities are called Sprints. You can't do them all the time. A Sprint is a defined burst of energy- maximally applied. Anything else is a different kind of race. Business as Usual, is a marathon for instance. But, occasionally, you need to produce a Sprint to Meet The Date (TM). Point is that the GP's PM-in-question might have accomplished more with better honesty relationships including a well thought out & generous TOIL [1] program that could compensate for the off chance that some institutional shortsightedness at an earlier planning stage- where commitments were made that may have seemed like a good idea at the time- proved more difficult than anticipated and resulted in a need for Sprints. [1] https://citrushr.com/blog/leave-absence/what-is-toil-and-how-does-it-work/ https://citrushr.com/blog/leave-absence/what-is-toil-and-how...

wpietri 5y ago
I agree that The Date™ is sometimes driven by legitimate factors. And that other things often become tied on to The Date™. But The Date™ also is a BFD when none of that is true. And if things like client training and penalty clauses were all that important, people would be extremely careful about picking dates that are realistic. Instead, frequently The Date™ is made up and people get fetishistic about Meeting The Date™ in ways that are untethered from actual circumstances or consequences. That's a sign to me that the real purpose of The Date™ is not the nominal purpose. > There is a reason some activities are called Sprints. You can't do them all the time. This is a perfect example of how distinct the nominal purpose and the actual behaviors are. In the Scrum framework, things are structured as an unending series of Sprints, back to back from here to eternity. Whereas in reality, a sprinter like Usain Bolt runs, what, 10 or 20 officially timed races per year at under a minute each? And the rest of the time recovering, prepping, and training.

darkerside 5y ago

Organizations make promises to close deals. Customers usually don't care how long it takes as much as they care about when they need it. There is variability in the bandwidth of those constraints (and in price paid) which is why we have a sales process. At the end of that process, making changes is really hard. So here we are.