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...
Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
61–66 of 66 posts
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#62I'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 "writ…
Take your original estimate, double it, and move to the next higher units. A one hour job ends up taking two days. Two weeks goes to four months. Scarily enough, I've worked with people whose multipliers are this large.
i independently developed that rule! ;-) works well in most multi-discipline team based development projects
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#63I 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 c…
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)
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#64Every 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…
I spent (I think) about two years walking by a sign in the south loop that said something like "coming in October of 2005, Target" and I thought, well, that's a pretty bold estimate for completing a building. Damn if that isn't exactly when they finished. Maybe they were changing the sign periodically and I failed to notice.
Humans have been building stuff for millennia. Software, on the other hand is still a relatively new field.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#65One 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…
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 ar…
If, by default, you assume the worst in your employees, they will eventually ALL start to behave in the worst ways. Why? Because every time they're honest with you, they get screwed when you assume they're just trying to get the better of you. So they'll eventually either be fired, or learn to lie to you.
Re: Coding, Fast and Slow: Developers and the Psychology of Overconfidence (2013)
#66One 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…
Angry managers are those who are not doing their job. I find that the effectiveness of the manager is directly related to just how angry they get. Usually, the very angry manager, is an incompetent junior - as in, cannot do his juniors job. This is typical. But when a team decides to support its own organizational structure, and thus support the manager in doing his/her job, then things do work.
Its just that people are often-times so bad at communicating with each other. Anger rarely helps there, either..