Cognitive Biases in Software Engineering
jonathanklein.net
jonathanklein.net
There's definitely way too much crankiness in the software world, and I don't think it's because the people are naturally negative people. It's because we're pragmatic people and we unconsciously gravitate towards the styles of communication that get the most results.
Interesting. I'd gotten the impression that negative comments were a form of dick-waving. I.e., if you can spot the the numerous flaws in some tool or concept then you are clearly the superior-minded hacker.
But I've never thought about it in terms of idea adoption or whether positive comments might have a lesser effect on people.
I wonder if negative comments play off people's fear of being wrong or fear of being seen on the "losing" side.
Maybe if you hear that there are good points for both Dreamweaver and [emas|vi|sublime] and it's a matter of personal preference and what works for you, then it's just some bit of data to file away. OTOH if you hear that Dreamweaver is simply evil and profoundly flawed then your adrenaline spikes; you don't want to be one of those people who use that tool.
Kind of disappointing if true.
As opposed to worrying about whether or not your decision was the right one because all of the options had really good upsides.
In reality I am trying to ensure the success of the project-- FAILURE IS THE DEFAULT OPTION.
The planning fallacy is a tendency for people and organizations to underestimate how long they will need to complete a task, even when they have experience of similar tasks over-running.
When something goes wrong, it's so easy to pull the "accountable party" into the CTO's office and give him an earful, but it is so wrong, so ineffective, and so anti-progress it's not even funny. Not funny at all.
The correct solution is the blameless post-mortem that Etsy does, as mentioned. Kill all fear of punishment, bring out the honesty and systemic analysis, and recognize the complex factors involved to come up with a real solution.
This type of thing is exactly what's required for a successful engineering culture, and for quality to be able to flourish. Give in to your reptilian instincts to get mad at a figurehead, however, and you'll kill your company culture and your quality all at once.
That isn't estimation. That is pulling a number out of your ass. Try something for me. For each of these data points, write down a low estimate and a high estimate that give you a 90% probability of being within that range.
Surface Temperature of the Sun: Low [___] -- High [__] Latitude of Shanghai: Low [___] -- High [__] Area of the Asian continent: Low [___] -- High [__] The year of Alexander the Great's birth: Low [___] -- High [__] Total value of U.S. currency in circulation in 2004: Low [___] -- High [__] Total volume of the Great Lakes: Low [___] -- High [__] Worldwide box office receipts for the movie Titanic: Low [___] -- High [__] Total length of the coastline of the Pacific Ocean: Low [___] -- High [__] Number of Book titles published in the US since 1776: Low [___] -- High [__] Heaviest blue whale ever recorded: Low [___] -- High [__]
Now, you might think this is a silly exercise because you don't have experience with the scale of these things, but how often do you estimate the time it takes you to build a product you aren't yet familiar with something using a tool you're not yet familiar with or people you aren't familiar with?
The answers are here: http://my.safaribooksonline.com/book/software-engineering-an...
(This quiz is taken from Software Estimation by Steve McConnel (Microsoft Press, 2006) and is copyright 2006 Steve McConnel. All rights Reserved. Permission to copy this quiz is granted provided that this copyright notice is included.)
Are you advocating something different here?
The first antidote is educating people about interdependencies and overconfidence. The second is introducing management.
Rails is more than capable of serving an intranet application for your 150 employees. But nooope, we're an enterprise, so we need J2EE/Oracle.
Sadly, at the larger companies, and especially ones where software is a cost center, this is basically impossible. They'd rather replace their last bullshit app with a new bullshit app, since it was the last director responsible for that POS anyway, making all the same mistakes as before, and rely on collective delusion (i.e. threats) to get everybody to go along with the idea that the old mistakes are being corrected, and that mistakes made now, if any, are at least new ones.
Maybe it's the same at startups. I wouldn't know.
What do you call this bias? People like to think that if a different person had been in charge, or if they'd had more time, then things could have been done "properly". But really there is no "proper" way to do anything in software engineering. Every decision is a judgement call. Everywhere you look it's shades of gray. Especially without the benefit of hindsight.
I don't know if this is a negative bias. Popular tech is well understood with known risks. Successful outcomes in software are hard enough without adding unknowns to the equation.
For example, lets say you're asked to submit a survey of the suitability of a bunch of languages for a new project; say Python, Java, PHP, C# and Ruby. You may give Python 8/10, Java 7/10, PHP 6/10, C# 7/10 and Ruby 8/10.
Now, imagine that instead of that survey, you were invited to a meeting where the chief architect informs everyone that the they haven't decided whether to use Java or C# yet, and since the CEO suggested PHP they decided to open it up for comments. Would you still give the same scores?
The classic experiment for this used a social music website, where people could vote for what they liked. Unknown to the users, they were internally separated into groups, so that people in group A only saw scores based on other voters in group A, and so on. In each group, there were a couple of really high-scoring songs, with the rest scoring very badly; but the each group had chosen different songs as their favourites! Those which were regarded highly in group A were seen as terrible by group B, and vice versa. As a control, one of the groups was never shown any scores at all, so their votes were less biased. That group showed much less extreme results, with some songs scoring better than others, but not massively so.