5 ms·

While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, i

While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.

agumonkey 8y ago
Isn't there some pseudo quantitative form of estimation based on a first draft system network diagram ?
tcmb 8y ago
If you can't be flexible on the delivery date, you have to be flexible in feature scope. That means building a simple verison first that still fulfills the purpose while not being perfect or polished. Then iteratively improve it to what you and the customer ideally want. That way, if the deadline comes before you're done, you at least have a working version that fulfills the basic need and allows the kind of workflow that's necessary, even if it still has some rough edges or even gaps in rarely used areas. Of course this approach requires you to write your contracts in a way that doesn't tie you down too strictly on how exactly things will be solved.
- zdragnar 8y ago
  Sadly, when it comes to contracts, that gets boiled down in most customers' minds to: "Vendor only commit to delivering buggy and incomplete software". It's a hard sell for most types of projects, even if it's the actual reality of most projects.
  - chii 8y ago
    You sell a small portion, for the same smaller price tag. Then when the deadline comes, the customer checks to see if you delivered, and decides to continue the contract or find somebody else. So the customer can have assurances that they aint gonna be bogged down with sunk costs. The developer can have more frequent deliveries.
wwarner 8y ago
Disagree. Upper and lower bounds can be realistically estimated. Whether the estimates meet the demands of the market is another question. I'm an engineer, not a CEO or sales person, but I'm a firm believer in selling first and building it later. Building it after it's been promised is one of the best ways to limit scope.
- rossdavidh 8y ago
  I have seen "realistic estimates" be off by multiples. Also, "build it after it's been promised" is not making any sense to me, perhaps you can restate that somehow?
- ryan-allen 8y ago
  > but I'm a firm believer in selling first and building it later Please elaborate! :)
  - wwarner 8y ago
    In a word, it's "agile". Let me first acknowledge that there my thoughts are a mixture of the types of projects that I've been working on, my own personality and my own path dependent experience. In particular, my way is intentionally short sighted and won't work for a project plan that takes five years. Also, for sure, if the sales team/ceo is wrong and the project isn't worth doing, then doing it "lazily" won't fix that. But with that out of the way, here's what I mean. The engineering team has it's own values and priorities and they just don't have anything to do with what really matters to customers. In the end, everyone brings in emotional baggage from the last project they worked on, and that's what's important until new information comes in from customers and the sales team. So what I shoot for is taking the requirements that we have and producing a long range design that will meet those and little more, and then producing features as quickly as possible and presenting it to the customer (or the customer's advocate). Why does it limit scope? Because the deadline doesn't move! To meet the most important requirements in a way that actually sells the product, lower priorities are are cut or reframed.
- chii 8y ago
  > Building it after it's been promised is one of the best ways to limit scope. only if those doing the promising knows what's within bounds and what's wildly off bounds! If the sales person makes wild promises because his commission depends on making the sale, but not the delivery, then the whole organization's interests are not aligned properly, thus fail. If the salesman's commission comes from successful delivery, then he can bring in an engineer who can at least balance the promises. Who knows, may be different departments can cross-contaminate, leading to a better, more well rounded organization.
mden 8y ago
and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwise how should managers or product people decide what should be done next? A big part of the issue is we don't have good knowledge how to estimate work. It's not a skill that is heavily invested in and is wrongly assumed as an inherent ability.
- rossdavidh 8y ago
  I have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.
  - codycraven 8y ago
    I have this sort of discussion, at minimum, three times a week (we're in-house developers). Very often the project scope isn't even defined and upstream dependencies are known to be critically lacking and will need to be augmented to even perform the work. Yet we're always pressured for dates and the caveats given are immediately forgotten and almost never communicated. The biggest pet peeve is when I give an estimate such as "I don't currently see a reason why we can't deliver X by the end of next week, assuming no other priorities come up." Of course something more important comes up in the mean time and I get scolded in a large meeting with a statement such as "You promised me I'd have X by Friday!" — this is especially infuriating when it is the PM's other project that is the higher priority interruption.
    - lifeisstillgood 8y ago
      It might not be viable, but I used to "publish" internally my own project one pagers, and update the timelines - any discrepancies simply became a shield for this future arguments. In short it sounds like you don't have the power to say no - but actually you do.
wwweston 8y ago
You could argue that these are some of the many forms of "starting late": * If you just don't know how long something is going to take, and you need a date, then you're late to doing the work to know how long it will take. * If you do know how long something is going to take, and it's longer than a externally imposed date, then you know exactly how late you are. This is partly just playing with semantics, but it's also a way of talking around different views of the problem, in this case emphasizing that if dates are a feature, reasonable estimates are themselves a project. If the estimate work hasn't been properly completed and understood before dates are given, obviously, the larger project is by definition already late because there's work that needed to be done before beginning and wasn't. And I think if you take this view, it's easier to see that it's a project or team management problem rather than an engineering productivity problem.
- lodi 8y ago
  I completely agree; you discover timelines in the process of doing the work. The problems start when you need to give an estimate before even being allowed to start working on something.
- rossdavidh 8y ago
  In at least some cases, you have to be halfway into doing the work (or more) before it becomes apparent that there is a big, previously-unknown subtask or requirement that invalidates the plan for doing it. In other words, if you really know enough to give a good estimate, you are probably mostly done.
watwut 8y ago
It is not about it being unknowable. If it would, the estimates would be all around the place. Sometimes short sometimes long. Instead, we systematically underestimate.
kgilpin 8y ago
I think you’re missing the point of the article. His original theses was that we aren’t good enough at estimation. And in fact much hand wringing over estimation has been done in this industry over the last 6+ decades. Now he’s amending his opinion to state that estimation is not really the core issue. The core issue is that projects are doomed from the start by mismanagement. Issues such as: racing to catch up with a competitor (giving the s/w group an impossible deadline), or starting a project whose business value is so low that minor time and cost overruns reduce the actual value to below zero (at which point people start blame shifting to try and hold on to their jobs).

agumonkey 8y ago

Isn't there some pseudo quantitative form of estimation based on a first draft system network diagram ?

tcmb 8y ago

If you can't be flexible on the delivery date, you have to be flexible in feature scope. That means building a simple verison first that still fulfills the purpose while not being perfect or polished. Then iteratively improve it to what you and the customer ideally want. That way, if the deadline comes before you're done, you at least have a working version that fulfills the basic need and allows the kind of workflow that's necessary, even if it still has some rough edges or even gaps in rarely used areas. Of course this approach requires you to write your contracts in a way that doesn't tie you down too strictly on how exactly things will be solved.

zdragnar 8y ago
Sadly, when it comes to contracts, that gets boiled down in most customers' minds to: "Vendor only commit to delivering buggy and incomplete software". It's a hard sell for most types of projects, even if it's the actual reality of most projects.
- chii 8y ago
  You sell a small portion, for the same smaller price tag. Then when the deadline comes, the customer checks to see if you delivered, and decides to continue the contract or find somebody else. So the customer can have assurances that they aint gonna be bogged down with sunk costs. The developer can have more frequent deliveries.

wwarner 8y ago

Disagree. Upper and lower bounds can be realistically estimated. Whether the estimates meet the demands of the market is another question. I'm an engineer, not a CEO or sales person, but I'm a firm believer in selling first and building it later. Building it after it's been promised is one of the best ways to limit scope.

rossdavidh 8y ago
I have seen "realistic estimates" be off by multiples. Also, "build it after it's been promised" is not making any sense to me, perhaps you can restate that somehow?
ryan-allen 8y ago
> but I'm a firm believer in selling first and building it later Please elaborate! :)
- wwarner 8y ago
  In a word, it's "agile". Let me first acknowledge that there my thoughts are a mixture of the types of projects that I've been working on, my own personality and my own path dependent experience. In particular, my way is intentionally short sighted and won't work for a project plan that takes five years. Also, for sure, if the sales team/ceo is wrong and the project isn't worth doing, then doing it "lazily" won't fix that. But with that out of the way, here's what I mean. The engineering team has it's own values and priorities and they just don't have anything to do with what really matters to customers. In the end, everyone brings in emotional baggage from the last project they worked on, and that's what's important until new information comes in from customers and the sales team. So what I shoot for is taking the requirements that we have and producing a long range design that will meet those and little more, and then producing features as quickly as possible and presenting it to the customer (or the customer's advocate). Why does it limit scope? Because the deadline doesn't move! To meet the most important requirements in a way that actually sells the product, lower priorities are are cut or reframed.
chii 8y ago
> Building it after it's been promised is one of the best ways to limit scope. only if those doing the promising knows what's within bounds and what's wildly off bounds! If the sales person makes wild promises because his commission depends on making the sale, but not the delivery, then the whole organization's interests are not aligned properly, thus fail. If the salesman's commission comes from successful delivery, then he can bring in an engineer who can at least balance the promises. Who knows, may be different departments can cross-contaminate, leading to a better, more well rounded organization.

mden 8y ago

and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwise how should managers or product people decide what should be done next? A big part of the issue is we don't have good knowledge how to estimate work. It's not a skill that is heavily invested in and is wrongly assumed as an inherent ability.

rossdavidh 8y ago
I have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.
- codycraven 8y ago
  I have this sort of discussion, at minimum, three times a week (we're in-house developers). Very often the project scope isn't even defined and upstream dependencies are known to be critically lacking and will need to be augmented to even perform the work. Yet we're always pressured for dates and the caveats given are immediately forgotten and almost never communicated. The biggest pet peeve is when I give an estimate such as "I don't currently see a reason why we can't deliver X by the end of next week, assuming no other priorities come up." Of course something more important comes up in the mean time and I get scolded in a large meeting with a statement such as "You promised me I'd have X by Friday!" — this is especially infuriating when it is the PM's other project that is the higher priority interruption.
  - lifeisstillgood 8y ago
    It might not be viable, but I used to "publish" internally my own project one pagers, and update the timelines - any discrepancies simply became a shield for this future arguments. In short it sounds like you don't have the power to say no - but actually you do.

wwweston 8y ago

You could argue that these are some of the many forms of "starting late": * If you just don't know how long something is going to take, and you need a date, then you're late to doing the work to know how long it will take. * If you do know how long something is going to take, and it's longer than a externally imposed date, then you know exactly how late you are. This is partly just playing with semantics, but it's also a way of talking around different views of the problem, in this case emphasizing that if dates are a feature, reasonable estimates are themselves a project. If the estimate work hasn't been properly completed and understood before dates are given, obviously, the larger project is by definition already late because there's work that needed to be done before beginning and wasn't. And I think if you take this view, it's easier to see that it's a project or team management problem rather than an engineering productivity problem.

lodi 8y ago
I completely agree; you discover timelines in the process of doing the work. The problems start when you need to give an estimate before even being allowed to start working on something.
rossdavidh 8y ago
In at least some cases, you have to be halfway into doing the work (or more) before it becomes apparent that there is a big, previously-unknown subtask or requirement that invalidates the plan for doing it. In other words, if you really know enough to give a good estimate, you are probably mostly done.

watwut 8y ago

It is not about it being unknowable. If it would, the estimates would be all around the place. Sometimes short sometimes long. Instead, we systematically underestimate.

kgilpin 8y ago

I think you’re missing the point of the article. His original theses was that we aren’t good enough at estimation. And in fact much hand wringing over estimation has been done in this industry over the last 6+ decades. Now he’s amending his opinion to state that estimation is not really the core issue. The core issue is that projects are doomed from the start by mismanagement. Issues such as: racing to catch up with a competitor (giving the s/w group an impossible deadline), or starting a project whose business value is so low that minor time and cost overruns reduce the actual value to below zero (at which point people start blame shifting to try and hold on to their jobs).