
Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013) - sidcool
http://blog.hut8labs.com/coding-fast-and-slow.html?reddit
======
rayiner
One of the best things you can do in your organization is create a culture
that treats obstacle discovery as forward progress. There is nothing more
disheartening for an engineer than banging her head against the wall trying to
debug some race condition only to get flak from management about why it isn't
fixed and why it's holding up some milestone. The root of this problem is
management that doesn't understand the problem domain, and is suspicious about
whether the engineers are really working diligently. The proper response to
obstacle discovery is to treat it as forward progress. Firing off an email to
a superior saying: "I discovered an unknown race condition, let's see what we
need to do to fix it," should be treated no differently than "I finished this
feature." The presumption should be that the engineer used due diligence and
the situation was unforeseen. Now, that doesn't preclude separate improvements
to diligence procedures to provide better foresight in the, future but under
no circumstances should anyone be blamed for discovering obstacles or defects
and raising them. When your culture does that, all you'll get is shitty
product.

~~~
gfodor
Just to play devil's advocate, there is also the type of person who tends to
get stuck down rabbit holes more than they should. There's a skill not just to
solving problems but avoiding them in the first place. Usually this requires
not just engineering talent but the ability to see the bigger picture, in
terms of product and business goals. If someone is banging their head against
the wall, it may be because they are trying to solve a necessary difficult
problem and are discovering valuable knowledge, or it could be because they
are foolishing running into a wall that they could easily go around if they
stepped back for a second and considered what they had set out to do in the
first place.

In your race condition example, it would be the difference between an engineer
debugging a race condition in mission critical code, and debugging one that is
incidental complexity in a unit test or ancillary tool that could be
refactored to be single threaded, or just omitted altogether. Heck, even in
the mission critical code case, it's worth considering how many users it
effects, how it effects them, and at every moment considering if the time
spent so far on the problem (and its associated opportunity cost) is still
justified. (Taking into account the fixed costs of switching context into the
problem again.) It's very easy to get wrapped up in an interesting problem and
forget about the eject button.

~~~
zenogais
This is where "The presumption should be that the engineer used due diligence
and the situation was unforeseen" clause enters into play.

I've seen many folks in management just always assume incompetence or rabbit
holing on the part of engineers. It's good to ask clarifying questions. But as
a manager you should be aware that adopting a style of second guessing and
interrogating everything your reports do comes off as insulting - after all,
you likely hired them, so why don't you trust them?

That being said there are no hard and fast rules here, and being aware of the
different histories of different folks is important, but defaulting to a
critical attitude is likely to lead to all types of efforts to hide things
from you just to avoid questioning, feeling insulted, having their time
wasted, etc.

------
kator
I've been developing for 30 years. When asked for an estimate I spend time
thinking about it and then when I come up with a number I multiply it by 3.
Usually this works but sometimes I can be off. My typical process is to score
stuff from "totally get it" to "don't have it all in my head". I then guess on
hours and in the end multiply by this 3 factor.

When my clients complain about the estimate I often say we "write software":

    
    
       1) The way the client thought it should be written
       2) Again the way the developer thought it should be written
       3) And finally the way is should have been written in the first place
    

I don't remember where I picked this up at, it was eons ago, but the axiom
seems to work.

When my teams give me estimates I almost always fudge by this 3x factor when
working with my stakeholders and explain how hard it is to really estimate
development without wasting tons of time doing massive waterfall charts. Then
they ask for the chart and I laugh "but then it'll be wrong two seconds after
we publish it."

In all my years of coding there have been "wow that went fast" times on
projects and "oh man I'm dying here" and the more room I leave to reduce
stress in the "dying" phase the easier it is to break free and get back to
"fast" mode.

~~~
anthay
But you risk your manager (if you have one) telling you you are "sandbagging."
And you might see others on your team tell your manager "it's no big deal - an
hour or so of work". And they slap some crap in there that whacks the mole
down long enough for the manager to make a mental note to give your team mate
a bigger raise than you.

~~~
Ntrails
If you want shitty work that creates a mountain of technical debt, I can do
that (no, really, I'm a natural at it).

If you want a thought through process that covers all of the points as best I
can, I will do that.

Align my incentives. But don't complain because I do the optimal thing

------
padobson
Every project has 'gotchas'. And I don't mean just every coding project, I
mean every project anywhere, ever.

Part of the key of navigating those 'gotchas' is to immediately communicate it
to your stakeholders when you run into one.

Sit down and watch HGTV for a an hour or two, and you'll see that carpenters,
plumbers, electricians, and HVAC contractors all run into problems -

'Whoops, this wall is load bearing, we'll need a beam here and it's going to
take us another 3 days to add it.'

'Your main drain is made out of clay, and we'll need to spend 25% of your
budget to replace it, looks like you won't be getting that powder room after
all'

'The main of your HVAC stack is right where you want to put that doorway,
we'll have to spend another $5k on this project to re-route it.'

People that typically finance projects are used to hearing these kinds of
problems. Don't assume they won't like hearing them and will fire you - that's
a huge mistake. Be honest and upfront with them. Problems like these are not
your fault, just be clear on what it's going to take to fix them.

~~~
jiggy2011
The difference between programming and construction projects is that property
owners have usually already invested huge amounts of money into the property,
so an extra few thousand doesn't seem like a huge deal and the extra work is
often financed as part of the mortgage. Construction contractors also don't
promise "magic" like programmers do.

~~~
padobson
A few things:

80% of the projects I've worked on already had code written for them when I
showed up to work on them. There's no difference between the existing
investment in legacy code and the existing investment in a property.

New home builds also have gotchas.

Programmer's promising "magic" goes back to my original point of communicating
with the stakeholders. If you're promising "magic", you're just asking for the
project to fail. Be clear an upfront, and your customer will realize you're an
engineer and not a miracle worker.

~~~
jiggy2011
Property investment is a little different because you can usually recoup at
least some of the money spent at a later date by selling the property. A
building without a wood rot problem will always be worth more than one with
one, especially when the problem is likely to get worse over time if it's not
dealt with.

A software project on the other hand is typically worth close to nothing if it
doesn't fulfil it's requirements , so the sunk costs are different.

To the second point, the problem with programming projects is that you are
often competing against more enthusiastic and less experienced devs who are
naive and under estimate.

------
BrandonBradley
'The key is that you first accept that making accurate long-term estimates is
fundamentally impossible.'

My life has been much better since I accepted this. Thanks for the reminder.

------
falcor84
The obligatory reference to Hofstadter's Law: It always takes longer than you
expect, even when you take into account Hofstadter's Law.

[https://en.wikipedia.org/wiki/Hofstadter's_law](https://en.wikipedia.org/wiki/Hofstadter's_law)

------
nevergetenglish
To estimate the time required to design your system you need to estimate the
variance of the time required. A well known result is that the variance of a
sum of independent variables associated to independent problems is the sum of
the variances of the subproblems.

What this mean in practice? It means that you should try to decompose your
problem in independent and dependent subproblems (perhaps associated to
features). Independent subproblems their variance, the formula for dependent
problems depends of the correlation between them.

What I am trying to say is that if you know a little math and have an
intuitive knowledge of the structure of the problem divided in sub-problems
you could make a much better estimate of the variance (and this mean there is
much less uncertainty in the delivery time). One could design a program that
constructs a graph and a knowledge base of previous programs that you have
designed. The graph edges should be weighted in accordance with the
correlation factor of dependency of those components.

Now that I am writing this, it seems very likely that someone has implemented
such a scheme to estimate time delivery. Perhaps there are start-ups using
this system to estimate delivery time, since all this is basic math.

Edited: Mostly grammar.

------
igammarays
This is why I've learned to always under promise and (try to) over deliver.
Whenever I think a project may take me 4 hours, I tell them 3 days. 1 week = 1
month, and so forth.

Another valuable technique is the Pomodoro one, dividing one's work into
intense 25 minute chunks of time. One then starts to think about work in terms
of number of Pomodoros, giving oneself better a better idea of quantities of
work. There are other productivity and health benefits as well.

------
bmj
Previous discussion here:
[https://news.ycombinator.com/item?id=5596578](https://news.ycombinator.com/item?id=5596578)

------
diltonm
It's an excellent article, at least three different times I caught myself
shaking my head in agreement. I really liked, "Congratulations, you’ve just
invented Waterfall.".

------
Animats
Why does programming have this problem? No unions.

Really. Compare film scheduling and construction scheduling, which are well
developed disciplines. That's because, in those industries, there's paid
overtime, and at rates higher than straight time. Thus, "crunches" caused by
overoptimistic scheduling add labor costs, which come right out of the
company's profit.

This forces scheduling discipline on management. There's a tendency to
overestimate, rather than underestimate.

------
tedks
It is possible to become better calibrated for long-term predictions. This
takes a longer amount of time, but is still doable. It's an intuitive process,
and the way I do it relies on discovering the true probabilities associated
with various feelings of confidence I have in a given domain.

The best tool I've yet found to do this is PredictionBook.com. It could use
things like tags support (so you could see your accuracy for sports separately
from your accuracy for development), but it's still useful overall. I've
gotten much better at being accurate, especially for 90% predictions, which is
a useful benchmark.

------
dschiptsov
The old maxim goes like _10 lines per day on average (of fully "developed" and
tested code)_.

90% of time should be spent on studying textbooks, reading other people's code
(only the best authors, like Joe Armstrong or Simon Marlow or Rich Hickey, you
know), [wishful] thinking, visualizing, drawing diagrams (using a pen and
paper, no UML and shit), writing pseudo-code (like they do in AIMA),
[unit]tests (before code!) and _then_ just 10% of time for coding, when you
know what exactly you are doing _and why_.

This, by the way, is called "slow thinking".)

------
svec
I've enjoyed their blog, especially "Speeding Up Your Engineering Org, Part I:
Beyond the Cost Center Mentality".

If the author(s) are reading this, when will Part II come out???

------
jawngee
Interestingly, I seem to have the inverse problem. _People telling me how easy
it is_.

I don't do web dev as a matter of course these days (I did nothing but back in
the day though), but once in awhile I help a friend out with their portfolio
of sites. Usually easy updates. But the conversation almost inevitably starts
out with, "Do you think you could take care of it? It should take a few
hours".

Of course, it takes two days.

------
kazinator
> _“We should just be more careful at the specification stage”. But this turns
> out to fail, badly. Why? The core reason is that, as you can see from the
> examples above, if you were to write a specification in such detail that it
> would capture those issues, you’d be writing the software._

Not true; a specification can precisely describe the properties of the
solution of a (sub-)problem, rather than the process of solving it.

~~~
JoeAltmaier
Its an iterative process that approaches code. The more abstract the language,
the closer the spec resembles the code.

~~~
kazinator
The closer are the abstractions in the coding language to those in the
specification language, the closer the spec resembles the code. If the two
abstract in different ways, then not.

------
ThomaszKrueger
I usually give "them" a shocker estimate, and my rationale is pretty simple -
unknowns. And for the most part my estimates are usually right. If asked to
trim it, I simply state that OK, I'll deliver what may not be the right
product but then it will become a matter of maintenance instead of
development. Your choice.

------
lordnacho
One thing I didn't see mentioned is moving goalposts. If you think something
is easy, you're more likely to accept adding some bells and whistles. So it
will take at least the time you set aside for it. Or more.

------
jgamman
i read this as a break from writing a functional spec. And i've already read
Thinking Fast and Slow. And I know that I'm going to be wrong. And I know that
no matter what i say to the client, they will say 'OK' and then wonder why i
missed the estimate. And i also know that this is what normal looks like and
when i'm in the middle of it and it seems as though it's a spaghetti diagram
of dependencies, it will work itself out so long as i keep chipping away at
it. this is a strange profession - i wouldn't build a bridge like this...

------
jonifico
The inaccuracy of your plan is equal to the amount of things you planned in
the first place. It's a lot more important to focus on a goal and react
according to what the journey throws at you.

------
wazoox
Indispensable reference to Joel:
[http://www.joelonsoftware.com/items/2007/10/26.html](http://www.joelonsoftware.com/items/2007/10/26.html)

------
amelius
One unaddressed problem with estimates is: if the developers finish before the
project is due according to the estimate, there is no motivation to start
doing new work.

How to solve this?

~~~
t0rped0
While it only happens on a rare occasion, whenever I finish my projects early
I'm always excited to show the client/management that we've been able to make
better progress. However, I'm extremely cautious not to let their excitement
alter their perspective about future estimates being completed early.

Another issue is that often clients/management will jump the gun into the next
phase after an early completion without allowing the devs a much needed break.
Perhaps this is one of the fears that keeps devs silent when (if ever) they
finish early, or stretching their work till the end of the original estimate.

------
marktangotango
>> if you were to write a specification in such detail that it would capture
those issues, you’d be writing the software

This is the key insight imo.

------
rectang
A rule I learned from my father:

Multiply any software estimate by pi.

------
michaelochurch
I tend to have a darker, more cynical view.

Asking for an estimate is often a power play or "microaggression". It's more
often about showing dominance than any legitimate business need to know this
unknowable quantity. It plays a programmer's present self against her future
self.

Her future self wants an accurate or even pessimistic estimate to be made, so
there are no unpleasant surprises to management and painful conversations
resulting from inflated expectations. But her _present_ self wants the guy
standing at her desk to go away so she can get back to work. An unreasonably
optimistic estimate gives the powerful, annoying people what they want so they
go away. A realistic estimate is going to lead to obnoxious follow-on
questions. "Why's it going to take so long?" "I don't know, but _experience_
leads me to think..." "But you see no specific reason why this can't be done
in 2 weeks?" "Well, no, because there are unknown unknowns..." "Great! Two
weeks!"

This degenerates for two reasons. First, managers tend to believe that, even
if overly optimistic estimates are more inaccurate, the work is done more
quickly with unreasonable estimates (which become "milestones", then
"deadlines"). So they take this as an incentive to be more irritating because
it "makes people work faster". Second, it leads to poor planning and brittle
schedules and much more undesirable variance.

Obviously, the good software managers don't play these games, but they're
probably 1 in 10. Because there is _so_ much money in software, and because
programmers refuse to organize and allow themselves to be underpaid, that
creates _lots_ of room for mismanagement. Developers are also to blame for
some of this; because they've been in mismanaged environments for years, many
of them have developed a distrust of management that has led them to
miscommunicate and (inappropriately) simplify, hence the "estimates" that
evolve into deadlines. Overconfidence and miscommunication are, for sure,
substantial components.

~~~
Roboprog
_Sometimes_ there are real deadlines, such as for regulatory changes.

But, yeah, often it's just bullying to drive a bad bargain. Most management
HATES iterative development, because it's too honest.

One of my favorite Ed Yourdon quotes: "Vote with your feet" (from "Decline and
Fall of the American Programmer, which scared the hell out of me, rightly so
in _some_ cases - and after working with off shore development, _that_ scared
the hell out of me)

------
paulhauggis
When management has no development experience, it's even more impossible. At
pretty much every place I've ever worked, features get added and the scope
changes many times before the project is finished. When it's not finished on
time, management likes to blame the developers and can't figure out why
nothing is finished on time.

