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.
Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
11–20 of 66 posts
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#12I'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
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.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#13>> 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.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#14Every 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'l…
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.
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.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#15Every 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'l…
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.
No I would rather argue that the difference is that software is not visible / tactile. When a construction project runs into a problem, you show the physical problem to the client and he gets it.
When a software project runs into trouble, the client has to trust what the developer tells him and immediately the client starts to doubt the developers' competence.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#16A rule I learned from my father:
Multiply any software estimate by pi.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#17Every 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'l…
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.
One of the biggest mistakes I see developers (and development companies) make is to define the edges of their project too narrowly.
Almost any piece of contract software development is intended to fit into a much larger system that has already seen heavy investment. Yet, often developers treat the software as an independent "thing" that they are creating.
For example, redesigning/rebuilding a corporate website is not (just) a web development project. The corporate site is one (often comparatively small) component of an operation that might include press relations, investor relations, social media, advertising, partner relationships, retail relationships, supplier relationships, etc.
Looking holistically at what a company invests in their corporate identity and marketing does two things. First, it provides very valuable guidance on the web site project itself. The new site is going to have to fit in with all these other activities. That's a set of very useful constraints.
Second, it puts the website project in its proper perspective. The company is not "replacing a building." They're replacing one component of a large multi-million-dollar marketing operation.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#18Earlier quoted context omitted.
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.
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 th…
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.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#19When 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.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#20One 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 p…
Interesting. This sounds like an Agency Theory issue.