Less Wrong is a community blog devoted to refining the art of human rationality. Please visit our About page for more information.

taryneast comments on Bias in capital project decision making - Less Wrong

40 Post author: jsalvatier 26 May 2011 06:06PM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (23)

You are viewing a single comment's thread.

Comment author: taryneast 26 May 2011 09:50:03PM *  3 points [-]

From the perspective of a software engineer, this sounds very familiar. Though in software it's generally estimating time-spent on producing features.

I'd also add: 5) engineers often totally forget about the black swans (or unknown unknowns) - especially obscure edge-cases that require special handling.

...though there's also one that I suspect doesn't happen often in chemical engineering: 6) scope-creep.. ie the client gets so enthusiastic about the idea that they keep adding to it until the final requirements are much bigger than the original

As to processes that seem to help keep down the overestimation. I find that velocity-tracking seems to actually work, if you can keep it up. ie measuring how much work actually got done and using it as a scaling factor on future estimations.

Comment author: SilasBarta 26 May 2011 10:13:25PM 3 points [-]

I'd also add: 5) engineers often totally forget about the black swans (or unknown unknowns) - especially obscure edge-cases that require special handling.

I'm not sure that's what is meant by a black swan, but in any case, this would be a factor only if managers more accurately predict the impact of these events. (If it's a case of known-but-unusual things happening in part of the problemspace, that's an issue of defining the problem appropriately for the engineers, and can be corrected before the solution is implemented without a higher time-discount or margin of safety.)

Comment author: katydee 26 May 2011 11:27:11PM 1 point [-]

It's almost certainly a reference to this theory, which essentially describes extremely difficult to predict events that have a disproportionate impact. Unfortunately the very nature of these events makes them difficult to control for.

Comment author: SilasBarta 27 May 2011 01:57:53AM 1 point [-]

I'm familiar with the term, and it's not the same thing as obscure edge cases that require special handling; rather, it's unforseeable events that have disproportionately large impact, nothing to do with being an edge case or requiring special handling per se. An unknown unknown that never has an impact is not a black swan. And something that requires special handling isn't a black swan if that "special handling" is known in advance (even if the fact that it will happen is not).

Comment author: Jordan 27 May 2011 02:28:13AM 3 points [-]

I think an unforeseeable edge case or bug that requires deep refactoring and severely cuts into allotted development time fits the bill for a black swan dead on.

Comment author: katydee 27 May 2011 06:42:42AM 1 point [-]

Understood. For some reason I misread your original post as saying that you weren't sure what a black swan was. I agree with your analysis here.

Comment author: taryneast 28 May 2011 09:01:09AM 1 point [-]

Yes, perhaps that should instead read:

5) engineers often totally forget about the unknown unknowns or even black swans.

Comment author: jsalvatier 27 May 2011 02:53:11AM 0 points [-]

I agree that 'black swan' isn't really appropriate here, but can you clarify what you mean by 'that's an issue of defining the problem appropriately for the engineers'?

Comment author: SilasBarta 27 May 2011 02:50:26PM 0 points [-]

I just mean that if you don't tell the engineers that special constraints apply in part of the designspace that render any design in that part horrible, it's not their fault if, not knowing this extra constraint, they offer that as their solution because it is otherwise optimal.

Comment author: taryneast 28 May 2011 09:00:01AM *  1 point [-]

Yes, that's true. and we should make sure that a client thinks deeply about all the cases that would reasonably come up.

...but I often find that there are situations that come up that really could not have been predicted in advance.

A small example for an e-commerce site might be the effect that adding multiple currencies has on dealing with "$X off" promotions if all you do is scale from a single currency you end up with $5 off or £3.24 off... which is ugly... and unfortunately required us to rework promotions to allow us to add "currency value overrides" for this kind of promotion.

It was unexpected, we didn't know about it in advance( either us or our clients) but it was obvious-in-hindsight that it would be unacceptable to the client/customers.

Comment author: SilasBarta 31 May 2011 05:40:54PM *  0 points [-]

I agree with you in that respect. If neither managers nor engineers are aware of special conditions that attach in part of the designspace until it catastrophically happens, then that is a black swan, and a reason to temper judgment with a higher discount rate.

I was only adding that if engineers come back with a solution that, given what they were told, is optimal, when the managers knew all along about special conditions make the proposed solution unfeasilbe, it's not a black swan, nor really fair to say, "silly engineers -- not accounting for the real world!" (It's at that point that you should re-iterate, adding that constraint to the spec this time and you certainly shouldn't go forward with it.) And that, if this is the problem, it's not the kind of thing that requires a higher discount rate or margin of safety, just better problem specification.

Comment author: taryneast 31 May 2011 09:48:12PM 0 points [-]

Definitely agree with you on that one. I'd guess it more a problem of scope-creep. You can also solve that by discounting, but it's much better to solve by enforcing different accounting for change-requests. I've found that if you keep time spent on scope-creep as a separate bottom-line, it draws more attention to the problem (which makes it more likely to get solved).