Good morning everyone can you hear me down the back there I can actually really see you too well at this light but mm heads Ephraim failing this morning any hangovers from last night phew phew I'll take the laughter as a yes and I'm still not feeling super great after the boat won the night before but I do have an emergency exit if I need it I'll be able to just kill the sand first and so Welcome to cognitive biases in software development um for the last 60 or 70 years researchers in social psychology and behavioral
economics have identified over 200 cognitive biases that affect our ways of thinking and I've been working in software development for nearly 20 years which is why I have such a long beard and when I've worked with hundreds of teams that I've seen them make the same mistakes over and over and over again and I firmly believe that Those cognitive biases are the underlying mechanism that causes a lot of these mistakes and that's what I'm hoping to kind of share with you today so my contact details are on the bottom there if you don't feel comfortable
putting your hand up and ask you in question in a room full of people and feel free to email me or message me on Twitter my DMS are open for now and so here you can message me there I want to identify you but I will answer the Question at the end if we have time otherwise I'll reply to you separately and if you are comfortable asking question please feel free to put your hand up at any time and if I can see you I will will call you um so to explore these cognitive biases
I want to use this very pretty thing so this is the cognitive bias codex and it was created by a person called buster Benson who is a marketing manager with slack and with the help of an illustrator to make it Look look very nice and he deduplicated those 200 odd cognitive biases into I'm told he's about 188 there haven't counted them and he kind of categorized them and group them into four larger areas now you're definitely not going to be able to read that from the back but we'll go through kind of each of these
areas and use that to explore and Buster said that all four of these areas he called him conundrums or problems they all affect or limit our Intelligence in certain ways and but they're actually trying to be helpful in in what they're doing and every one of these cognitive biases is actually there for a reason usually it's to save our brain energy in terms of how it processes information but unfortunately the end result of a lot of these mental shortcuts which are often useful and they also introduce errors into our thinking and that's what cognitive biases
really are and Buster Was quite hopeful he hoped that by creating this and sharing it and it's available on Wikimedia and that people will become aware or more aware of how our minds work how we make decisions and that we could be a bit more mindful about the inheritance of these inaccuracies and fallacies and hopefully that we'd act with more fairness and grace to each other so we wouldn't think of each other as being kind of stupid for having fallen into some of these Fallacies and I'd echo that sentiment as well I hope that we
can well I hope that I can share some of that with you today so we're gonna zoom in a bit onto the first area which is around kind of too much information and as you can see there um if you can read the kind of arrow ring this generally kind of our the cognitive biases that come about here are generally around where we have problems absorbing too much information our brains never evolved for the Internet we were not really prepared for it so we have to do a lot of trickery to be able to deal
with the amount of information that we take in and some of the things that happen because of that are the you know we noticed things already primed in memory or repeated often so things that are familiar to us will will kind of come to our memory first bizarre funny or visually striking things will stick out more than non bizarre or funny things and you remember Jokes in a talk hopefully we notice when something has changed and we don't notice when so we noticed when something has changed and this that kind of change is important for
us to be able to actually realize that it's there and we are drawn to details that confirm our own existing beliefs I'm sure we've all experienced that at some time or another and the last thing though is we notice flaws in others and I'm sure we've all noticed The previous one and other people a lot more than we've noticed it in ourselves as well so gonna jump into the the first cognitive bias that I'd like to talk about it which is called anchoring now anchoring arises from a heuristic a very common heuristic that we have
when we're making an estimate about something we will tend to start an initial point which we call an anchor and will then adjust I ran that and that heuristic isn't good or bad it's just a Heuristic and where the bias comes into it is that we then tend to stick too close to the anchor to give you a real world example of this if you've ever bought a used car you've probably been subject to this bias the sticker price that they put on the car is that initial anchoring point so once you become interested in
it and are bargaining with the salesperson around the price they know that you are then very likely to anchor onto that price and adjust around It now they know you're probably gonna adjust damn unless you're a terrible and negotiator so for them that kind of win of it is is that you're unlikely to adjust down too far so they set that price knowing that you'll want a 5-10 percent discount and if they give that to you you'll be happy they'll be happy because they still make a considerable profit so where we see this in software
development a lot is in estimation and forecasting for most Teams who are when that comes to estimation they will take a task someone will kind of maybe read it out loud to the rest of the team and then say I think this will take two weeks so what's happened there is they've immediately anchored the discussion of that task a common strategy that people use and agile teams in particular use is a technique called planning poker which takes away a lot of that bias and that can help in D biasing it but it is Also quite
common for people to be able to anchor with less kind of direct language even just by talking about a task and saying this looks like it's just a small UI change or it's only a database update you've already anchored people in terms of what you think that is and they are going to lock onto that stick to it even if they don't necessarily think that the task at hand is that small or only something or just something so it's Quite important to be very very careful of the language that you use when you are even
using techniques like planning poker and the I guess in terms of D biasing for anchoring and for anchoring and adjustment overall what I'd actually recommend is that you try and move away from expert based estimation so where you're asking people to make an estimate on something it's very very hard for them to get rid of this type of bias what we can use is what's called Model-based estimation where you use a mathematical model to actually generate an estimate and I've probably can't see that from the back and I would highly highly recommend the work of
Troy McGinnis Troy is a an Australian um who currently lives in Seattle works for a company or founded a company called focused objective and I highly recommend that you watch read listen and follow everything that Troy McGinnis talks about and got a focused objective calm To read through that he has a spreadsheets and existing templates that you can use to get started in this kind of model-based estimation so anchoring in its original form and reference or was based on cutting numeric values but we can also anchor on other ideas as well and we can get
pretty fixed in those and one of the things that we've seen in academic research around cognitive biases and to offer estimation is that particularly with new or Inexperienced developers when they're coming on project they will have a pretty poor understanding of the the actual solution itself they'll have a very limited view of what's in there and because of that they will actually anchor on their understanding of it so that can lead to I guess kind of poorly implemented changes and it can lead to them not really understanding how they need to change the application and
can introduce Bugs as well the other area that we see is in system designers so this is usually people with the architect title or architects and wearing their title no offense to them and sorry so system designers as I'm sure you're aware can be pretty you know precious about what they've kind of come up with and they will anchor on their original design pretty hard and there's a few other kind of biases which we'll get onto that feed into that as well And it can be very very difficult to D by aesthetic aynd of get
them out of thinking but explicitly asking them to generate alternatives and then potentially even using something like a model-based comparison where you're not asking for people's subjective opinion on them that can help 2d bias and the other option is to democratize those decisions so rather than having one person making a decision about your architecture and having all of that one Person's bias is going to feed into that you can ask the team I'm gonna jump on to the next bias if you've read Thinking Fast and Slow you'll recognize those these two and they're covered pretty
extensively in that availability bias is that the tenancy for easy to recall information to unduly influence perceptions or judgments so within the academic research and there's pretty strong evidence about that developers will only search documentation that's One that's easy to access for them and two they'll rely on prior knowledge or experience to figure out what documentation they need to go and look at so know we have Google and Stack Overflow and it's saved all of our lives many times and but our reliance on that and a kind of a tendency to go and search in
certain areas does itself introduce a bias in terms of when we're trying to find solution things so this can sometimes result in inefficient Searches and developers don't really know where to go to be able to access the information they need another effect M is if is associated with preferring a familiar but less suitable programming language who's ever experienced that a few and what's available to us is the language that we know so we are absolutely going to prefer that and the bison it is though is that will convince herself that it is the right language
for the job when it may not necessarily Be um JavaScript may be M and we also see the available availability bias manifest within project based organizations so organizations that tend to run in project and this is where they'll fail to learn the lessons from kind of previous projects so where they've completed a project they'll make the same mistakes kind of again again because they don't really have access to the information to learn from the previous previous and projects that They've done so um in terms of D biasing for availability it is pretty difficult again it's
one of those tough ones and participate participatory Jesus that was a tough one participatory and decision making so getting the team involved in the in decision-making can help with that and retrospective meetings whether you're doing scrum or not retrospectives are always a great idea having a point where you can kind of look back at what's happened in the project or look Back at the decisions you made and gives you a much better chance of D biasing from that and actually being able to stop making that mistake including people from outside the teams in those retrospectives
as well is a is a very very good tactic and and does give pretty good results from what what i've in practice as well and and particularly around in terms of directing developers to documentation one technique I've had really good success with recently is Building pretty good kind of role on documentation for new people in the team so rather than them having to kind of dig around within the source code or try and you know do I get a confluence do I go to a SharePoint is it in someone's file share somewhere instead you give
them a comprehensive role on document that tells them where to go exactly for what kind of information that they'll need that helps to alleviate to jumping on em framing and kind of closely Associated fixation is a tendency to disproportionately kind of focus on one aspect of a situation object or event and particularly impose kind of self imagined barriers on that as well so I'm gonna give you a story of a bit of an extreme example of fixation and framing in a way as well this is a book cover from a book published back in the
and it was the 80s I bet ya a plane crash if you can't see it and this is slightly dramatic eyes but not really too much This was United flight 173 so they were flying from Denver in the United States and to Portland pretty routine flight they'd already completed a lag I think from from New York and as they were coming into land they deployed their landing gear unfortunately one of the components of the landing gear a pneumatic tube exploded it didn't stop the landing gear from deploying properly so the wheels were tan but it
did sever the sensor to the landing gear so as far As the pilot the copilot the flight engineer were concerned they couldn't tell if their wheel was down now most of you probably fly quite regularly and you'll know the wheels are kind of underneath the wings so you can't even see there's no way to kind of look at into it so they're in a pretty tricky situation and Hadley reacted they radioed the airport where they were landing in Portland let them know there was emergency and they were put into What's called a holding pattern so
they moved away from the airport and just started circling while they tried to resolve the problem so the captain sent the first officer out to look and on the wing there is a little indicator that on the wing that shows when the gear is down but he wasn't able to see it um and in this time it took that kind of half an hour for all this the flight engineer noticed that they had about 4,000 pounds that's us pants of fuel left now that's Nothing in kind of airplane terms that's you know you need to
be getting in and landing on that the captain was so fixated on solving the problem with the landing gear that he didn't really hear the information the way they put it in the incident report afterwards was that he forgot to fly the plane captain forgot to fly the plane after another rotation another circle in this holding pattern and it really started to come to a head they kind of knew that they Needed to get down they finally realized that they'd made a huge huge mistake on it and they started to land and or started to
prepare to land now there was no way they could reach the airport at this stage there was no other airfield within close proximity but they did spot a dark area that they thought they could potentially land in unfortunately or maybe somewhat fortunately and that dark area was just a group of houses that happen to have their lights off so they Landed in between two houses and destroyed two houses the entire front of the plane was destroyed as well and the captain did survive inside of the flight crew unfortunately 10 people died in the accident now
that is an extreme extreme example but if you think about it I think we're all or we all can be a little guilty of fixating on things so much that we actually forget to kind of fly our own plane as well that kind of fixation is the thing that causes people To delete databases in production or to delete Google Calendar I feel so bad whoever did that couple of days back but that's what happens and it is an information kind of overload in terms of what we're doing so we to cope with it will actually
fixate on a particular thing and will frame it in a particular way so that we're able to kind of make sense on it and were able to to kind of move ahead with it one example I saw recently in terms of framing of fixation I was working with a DevOps team and air-quote because I think the idea of a separate develops team is that's a different talk and they were supporting team are supporting over 200 development teams and their work management system as your DevOps if you're interested they actually used a single team project to
keep all of those teams in to manage all the work that led to these massive pages of boards that people in those teams had to kind of scroll through to find their Own so over 200 and so they're like scrolling for ages to try and find the board that you're using the reason why they chose that structure was because they wanted to be able to do reporting so keeping them all on one team project made it easier for them to report it made their 200 developers teams lives but they were cool with it because they
needed to do reporting you know um so they're changing that anyway after the discussions that I've had with him And I hope I didn't scare in him about flying flying is incredibly safe and just that was back in 1970 odd and but the reason why I told that that one seven three story is what actually happened happened after it so after that incident and everyone felt incredibly sorry for the captain no one really he was blamed he was he lost he to lose his job so he was blamed in that way and but within the
industry most people just feel like he was very very unlucky he Kind of just got into a very bad situation and just focused on it too much and miss that just forgot to fly the plane what was implemented after that was what in the aviation industry they call crew resource management so CRM another CRM and CRM training was focused on teaching captain's how to delegate responsibilities appropriately and most importantly delegating the responsibilities of who is flying the Plane while we deal with this so would have been an obvious solution for the problems that they had
and they also teach the first and second officers to speak up when they're concerned and even introducing kind of formulaic openers like templates that they can use to be able to talk to the captain and say I think there is a problem they also taught them that sometimes the captain doesn't necessarily know better and when the safety of the aircraft is at stake And that they should take control of the plane so I think we can all definitely learn from that that kind of crew esource management and I have seen this start to become more
and more prevalent in teams and I'm not sure if Donovan talked about it in terms of what Microsoft do and their live psych teams and their responses and but cite reliable site reliability engineering teams will often have an incident response team and they have this kind of Delegation a very crew resource management type approach to it within our project teams and within our normal work as well and it's very important that we have that capability - and that we are able to delegate those tasks and we have someone who is focused on remembering to fly
the plane to actually help us deliver something of value cool so and the second conundrum the poster identified was not enough meaning to given all of the information that we Have or that we have the process we then have to filter that out kind of keep something or keep what some things are not always but we need to be able to build meaning from that to be able to I guess kind of improve our understanding and with that we tend to find stories and patterns even when we're looking at sparse data we can pull we
can tell ourselves incredible stories about things that we know very little about we fill in characteristics from stereotypes General generalities and previous histories and so we will fill in those gaps with things that we kind of have known previously again elaborating on the story that we're telling ourselves we imagine things and people were familiar fond with as better I think we'd all kind of agree with that and we simplify probabilities and numbers to make them easier to think about and we don't just simplify probabilities we are terrible at probabilities we are like so So bad
at probabilities it's just in just a natural thing and the last one there we think we know what other people are thinking so gonna jump in into one in particular which I'm sure you're all familiar with not invented here this is a general cognitive bias in that it actually does affect the wider world as well it's not just a software development thing and typically there it's where people will refuse to buy from another country like Norway won't Buy from Sweden is that that the kind of yeah um within software development we were familiar with we
actual call it not invented here syndrome so where it we have our own kind of name for it and it's a tendency towards reinventing the wheel and re-implementing something that's kind of already available has anyone ever built a kind of a CRM system yeah bespoke CRM system we've all done it um and it is kind of based on the belief that the there's a few Different reasons for it I suppose but they're typically its that they believe the in-house development will be better and might be more easily maintainable maybe kind of more secure or more
controlled and often people think that it's it's going to be easier to maintain and but that kind of thinking is I think that's an actual fallacy that we should probably investigate because every bit of code that we that we write always cost in Maintenance whereas a product that we buy is someone else's problem that's why the clouds so cool you know it's it's Microsoft or Amazon's problem they're not ours um and one of the things that I see really common is people writing their own authentication I cannot tell you how much of a bad idea
that is and the argument that I get from people is that oh well you know we'd only use someone else's or you know we were kind of we Know that it's gonna be more secure because we control it and what I always say to that is that if you think your security team is better than Microsoft or Amazon's you are deluding yourself in terms of that so please don't write your own and your own authentication one of the biasing techniques that I take with this particularly where teams are trying to make that decision of you
know do we buy something or do we build it ourselves and is to move to a model Based kind of approach for that actually getting them to forecast or estimate how much they think both will take will help them to start to think about that and help them to start to be able to figure that edge one of the things that you do need to factor in is that the lifetime maintenance of things um it's very it's a very easy kind of trap to fall into thinking that you know we're gonna build this for cheaper
than it would to buy it especially where you're paying millions Of dollars for products like s AP or some of those enterprise softwares um but the money that you're gonna spend in terms of maintaining that and the cost of delay that that is going to incur on everything else that you could potentially do needs to be factored into it as well I'm Troy McGinnis again has some really really good stuff around this and I can help you that can help you to kind of factor these things out and D buy some of these decisions Moving
on em policies are tough fun to say so the extrinsic incentive bias is a tendency for people to attribute relatively more to extreme extreme extrinsic incentives so that's things like kind of monetary rewards than to intrinsic accept the incentives such as kind of learning a new skill this is it's like I'm back in speech therapy again this is crazy and it specifically when weighing the motives of others so I'll give you a bit of an example of That to make it a bit clearer and a study was done on MBA students I think in Cornell
they were asked to rank the job motivations of Citibank customer service representatives these are frontline people on phones and answering queries from bank customers and this is what they came up with so probably worth calling it there is the amount of pay was the first one so they thought that the single biggest motivator for customer service representatives was the Amount of money they were paid and down below that was having job security kind of basic needs and quality of fringe benefits met appraised from your supervisor like a pat in the head will make everything better
and doing something that makes you feel good about yourself developing skills and abilities came all the way in Dan at six so in the study they then asked the actual customer service representatives what their real motivators were and they Said completely the opposite so the first one was developing skills and abilities and second one was accomplishing something worthwhile we all want to feel like we're doing something a man of pay came seventh if you can't see it too in the back there and and the amount of praise from your supervisor came last fully enough and
which I do think was interesting um and now you might be a bit cynical and say well this is what they say motivates Them but maybe that's not what actually motivates them but we do have information from a lot of eggs and interviews which backs up this result these are really the things that motivate people people will stay in nuts a nice environment where they are accomplishing something worthwhile anyone who's ever volunteered for anything can tell you that em and damping's drive is an incredible book about this I would HIGHLY highly Recommend it if you
haven't read it and covers a lot of this kind of what motivates us to do the work that we do there is some interesting stuff as well around back what's got a backfire effect and it is another kind of bias as well and where people are asked to are offered an intrinsic excellent an extra extra ins our consent if so where they're offered money to do a job that would normally be motivated by the other one and they'll actually perform worse So people will do worse so if I offered you money to like more money
to write software you will eventually there might be a bit of a peak at the start but you'll eventually start performing worse and you would have had a not so that backfire effect is a very very important one to watch out for and the recommendation from the study on this was to if you are trying to think about other people's motivations and that you focus on your own so rather than you Saying what do I think that person's motivations are just ask what are my motivations and use that to help yourself rank that M obviously
within software development where this kind of comes into play sometimes is when we start thinking about obviously our teams as leaders but also our end users so where we're trying to design a system for end users and trying to imagine what their motivations are going to be and don't think of them that way just think Of you as a user and the way that you can D by is that is by asking a larger group of people either a representative group of people or a diverse group of people much more preferably cool oh sorry that
was a bit we had to do a bit of rotation change and so hindsight bias is the last one in this section that we look at and an hindsight is the tendency to regard outcomes of having been predictable all along and there's a phrase in English called Hindsight is 20/20 so 20/20 is like perfect vision so it you always have perfect vision when you're looking back at previous things and within software development I've experienced this most when people are looking back at project failures so I've seen people look at things that there was no way
it was predictable but they are convinced that you know if we just done some kind of more investigation or just understood things a bit better that we would have Been able to predict it and would have been able to account for it and this just doesn't work and something that we use in ratify the company that I work for in Australia is what we call a kickoff deck so this is an example of the kind of first slide that we use where we're trying to get everyone on the same page and when what we experience
is that most of the time even within a company people have very different ideas about what they're doing And we're trying to get them all into to agree in it on one thing within that kickoff we will also agree what the vision for the project is or the engagement is what the objectives of it is and most importantly really what the risks are we have a fad then as a document and we share it with everyone on the project team everyone gets it from the customer and from within our teams as well and we're able
to then look back at that so when we come to the End of a project and we were doing a project retrospective we have the original agreed risks during the project we also report on these risks and objectives and opportunities as well that we're doing in a weekly email that we send out to all of our company so we have a full traceability through the project of where these risks occurred that way at the end of the project if something does go wrong we're able to look back and say well yes you know Maybe someone
did see the risk and maybe we didn't react to it appropriately and we can actually learn from that and that's a very very good way of deep biasing for that hindsight risk and the kind of effect of the hindsight bias is that people tend to lose faith in kind of things that they've done before or at least faith in people and when you think that they could have done more to be able to fix it you have a tenancy there to kind of Blame that on them when a lot of the times it wasn't really
their fault and well okay til a spoiler so has anyone heard of Black Swan theory few people down the back yeah cool um so this is a Black Swan surprise and the word the phrase Black Swan actually is it's a very very old phrase it comes the first noted I think was in Latin so it was really old if it was in Latin am and originally what it meant was that something that was impossible because Every European at the time had only ever seen white swans then one day in 1697 a Dutch explorer and I'm
gonna butcher this named William dove lemming I got it that was pretty good um sailed into Perth where I live and saw these little guys swimming around on what is now called the Swan River and that changed the meaning of the phrase entirely from something that was impossible to something that people thought was impossible um was quite hard To quite hard to predict but maybe in hindsight we could have kind of predicted it and black swan theory now is a bit of the study of that and there's some interesting things that have happened I guess
in the technology world that you could call Black Swan events I don't think anyone really saw how big the web was gonna be how much it was going to change the world I think a few people did um but not many and even things like Google I don't think anyone Especially Yahoo didn't see what Google we're gonna do they really really wish they had um but yeah the there are things that happen there Black Swan theories incredibly interesting to look at in terms of how do you try predicting zhh that happen or that that will
literally change the world you know how do you kind of try and foresee those right so moving on to the third section I'm still good for time and the third conundrum is that we we need to act fast So with all of the information that we've had and everything that we've pulled together the meaning that we've created from it we now need to make decisions if we are lost in an analysis paralysis or trying to figure everything out and we'll never get anything done we'll never be able to act quickly and get things there so
the kind of biases that we see around they saw that we favor simple looking options and complete information over complex and Ambiguous options and to avoid mistakes we aim to preserve autonomy and group status and avoid inevitable decisions or irreversible decisions to get things done we tend to complete things we've invested time and energy in and to stay focused we favor the immediate relatable thing in front of us and last one there to act we must be as confident we can make an impact and feel what we do is important so there's a few things
within there but I'd like to to kind of explore In a bit more detail the first one is that last one overconfidence bias has anyone met ever met an overconfident developer is anyone willing to admit that they have been an overconfident developer thank you um so overconfidence bias is the tendency to overestimate one skills and abilities and there's actually been quite a bit of academic research on cognitive biases specifically in software development around this so someone thought it was Enough of a problem to actually spend time investigating it which should tell us something about what
we do and within software development the way it manifests is and what the academic research found was that there is a tendency to produce overly optimistic estimates judgments and predictions surprise and defend some interesting things to which you may or may not like to hear that technical roles so developers and appear to be more Optimistic than non-technical roles like managers so your manager is better at estimating than you are and at least in in this particular study it was in web development tasks that they they found that in yeah but the the real implication is
that it's knowing more about specific kind of tasks can actually lead to less accuracy in terms of forecasting or estimation um one study as well suggest that Overconfidence leads professionals to neglect requirement analysis um leading to kind of a superficial understanding of the problem so they're they're kind of so confident and their abilities of what the solution is that they don't really invest too much time kind of investing it properly and I'm gonna stalk into project managers project managers often are overconfident in time and resource estimation and can lead to outright Project failure I don't
think any of us are really surprised at that em but overconfidence doesn't generally kind of operate on its own there's usually some other factors which come into play as well um confirmation bias is one that particularly hits in terms of an anchoring bias as well in terms of like giving us a poor understanding of what it is that we're trying to do in terms of how we we kind of de bias for Overconfidence it is pretty difficult to tell overconfident people to be less confident and but what we can do is use what's called directed
questions to attempt to elicit information from and from them like using schemes or checklists like in aviation CRM we've had like particular kind of questions that we can ask people um and encourage encouraging individuals and also organizations to engage in self-reflection so that kind of Retrospective process making that an organization or white thing can definitely help with that um around estimation and overconfidence in estimation there was an interesting result that even how you phrase questions can change the kind of output that you get from people specifically asking how much effort is required to complete X
versus asking how much can be completed in Y work errors and the Previous one gave much more kind of hot or much more overconfident kind of results than the latter and so effectively kind of focusing on tasks rather than on time and is a very good D biasing technique for overconfidence within there somewhat related to that and something you may have heard of before is what's called the the dunning-kruger effect and this is something we're all subjected to it's particularly problematic when you when You first learn so what Dunning and Dunning and Kruger were two
research scientists and what they discovered was that people mistakenly access cognitive ability as greater than it is and this is kind of related to another one which is a bit further up there called a loser a superiority where you kind of think you're better than everyone else um and the kind of corollary of this is is that competent students so while incompetent people overestimate how good They are and competent students actually underestimate how good they are so they they don't the incompetent don't think they're better than the competent but the competent don't know how good
they are yeah that was right um but illusory superiority and comes from the the kind of the internal illusion in people of low ability em and from like an external misrepresentation of high ability so they don't really understand kind of how incompetent they are does that make Sense so they're incompetently incompetent you may have heard of heard of that phrase before am and I think it was Krueger actually said if you were incompetent you can't know you're incompetent the skills you need to produce a right answer are exactly the skills that you need to recognize
what the right answer is I think that kind of sums it up quite well incompetent students though in the study that they did did improve their ability To estimate their rank correctly after receiving minimal tutoring and skills that they previously lacked so when they were kind of told about the skills that they didn't have they were able to kind of realize that they were still missing some things um in software development I kind of I know if you didn't you'd agree I think I've see this quite a lot um I'm the main areas when I
see it is actually when we're dealing with other kind of departments so I work A lot with salespeople and I work a lot with kind of project management or delivery management as well and I do think there is a bit of a pervasive kind of idea within software teams because we're kind of smart people I think that we think we know a bit more about kind of what they do then we really do I think we're on the in the dunning-kruger effect scale I think we're in there I know everything about what everyone else does
not sure if you agree maybe and the Problem with it is and the problem with the dunning-kruger effect is is that the the people that you deal with know that you're not good enough in universities where you're you're kind of you know when you first start in university you've got like a semester or two of something and you're I'm gonna tell this lecturer you know I'm gonna tell my professor what's what's all about this stuff that kind of overconfidence they're Happy to deal with that because they have to deal with it all the time when
you're dealing with people in business you just come across as an so that is the kind of that the effect that we're putting Adam people and that we think that we could do their job better than them am and it hurts us too as well like I've seen people move from particularly into kind of like leadership where developers will move into leadership thinking that they know Everything that they need to know about leading and they fell really hard and it's it's you know um not a good a good outcome for anyone turning offer then because
it's hard to take that setback interestingly for the ladies in the room on average men overestimate their abilities by 30% women only by 15% so you're a little better kind of judging your own abilities in their race you're not really surprised that em and Interestingly socioeconomics actually come into it to and individuals of relatively high socio-economic social class are generally more overconfident than lower economic class there's kind of cultural forces within their to attends to change within within regions or areas deep biasing for this and again it's a tough one because it's a it's very
internal things for people and but the biasing for this kind of mentality within your team I think is diversity is One of the best ways to do that so hiring people with much more to or from diverse backgrounds will give you a kind of a better blend of people to approach this skipping off and appeal to novelty I'm actually just not gonna say anything I'm just gonna show you this JavaScript frameworks um so the appeal to novelty is actually a fallacy it's not specifically a bias with itself um and it it's the fallacy is prematurely
claiming that an idea or a proposal is Correct or superior exclusively because it's newer modern so there's nothing wrong with novelty novelty is perfectly fine but when you kind of say that something is better because it's new that's the fallacy that were Pro but we're kind of talking about and it usually takes two forms it's either overestimating the newer modern or under estimating the status quo that kind of what was there previously and it may be that you know investigation kind of Proves it true in the future but the fallacy itself is that where you
just assume it automatically M and there's a very interesting kind of history of this within our industry and when it kind of the first dot-com boom back in the the 90s if you've has any watch valley of the boom from HBO I watched it on the plane over I like the whole series because I flew from that and it was really really super interesting it kind of covered that that Start from when neck Netscape's first kind of IPO and things exploded and that whole first dot-com boom was based off this fallacy it got like super
super crazy companies that didn't even have a website we're putting calm on the end of her name and their stock price was going up because of it like that it's just it was batshit em and it was because people believe this they were like a hot new it must be better so yeah let's do it Em one of the things I've seen in particular in software is where people will latch on to a new framework I had a colleague and who asked me for a bit of advice around what mobile frameworks they should use now
that the team that who's working with had been through - I wouldn't say they were bad they were they're a good project they delivered value out of them they had a lot of problems with the thing called xamarin forms which is Microsoft's can a Cross-platform mobile development framework and they they were kind of a bit sick of it you know so he was asking me about you know should we go to react native and I asked him um have you used it have you tried it out and he's led I've had a play with it
which is developer speak for I've read a blog post and I said listen like you know it's kind of up to you in the team I'm not gonna tell you one way or the other you do knows amber and you know where Your problems are gonna be um so you went away and they made a decision and three months later and he came back and said to me I should have used xamarin so they had like three months of problems um and that's well I think that kind of leads to the D biasing for this
particular one is that you need to investigate these things first you should not just invest in something new because it's new we're at argue against that in terms of novelty is where you're In a situation where you have kind of continues decay so if you're maintaining a vb6 app you know if you have to do that it's probably worth getting off that it's probably worth just saying yes let's go for the novelty and get away from it um but try not to do it where it's where it's not necessary um moving off ever so slightly
add the Sun cost fallacy who's heard of sunk cost fallacy before Yes Severn and it's a tendency to irrationally invest more resources in a situation in which prior investment has been made as compared to a similar situation which prior investment has not been made so let me give you an example so let's say I'm a government department for let's go at Sweden um and I'm I've got a project for an application that I'm trying to build and it's got a tender and the winning or the winning bid was 40 million dollars we Got to bet
a year later with the you know the projected kind of delivery date application still isn't there and the teams are the the vendors that I went with tell me that it's gonna cost them and it's gonna cost another hundred million dollars to be able to deliver it if I agree to that I have fallen prey to the the Sun cost fallacy and if you think about it you know that at the very start had that government department in Sweden being told that the project was Gonna cost 100 million dollars they would have said absolutely no
way if they had been told it would gone going to cost a hundred and forty million dollars they would have said not a chance so that's the the fallacy that's involved there I would have used knock but I really I cannot figure out how that that works with the comment um in game theory this is known as the Concord fallacy you might be getting an aviation Team bit of an aviation nerd and Concord was the I think the first and still the only commercial supersonic jet it was operated by the bridge funded by the British
and French government internally the British government admitted that it should never have happened it was a huge huge costly mistake for them but for political reasons they kind of had to do it em and this bias is somewhat related to one a couple above what's called the escalation of Commitment escalation of commitment is what happens after the the kind of the sunk cost fallacy where you've made that decision and there's been a lot of work done on em escalation of commitment specifically within kind of behavioral economics and it's kind of explained in three elements so
firstly the the situation has to have cost something time or effort and some are the time has passed an athlete led to a kind of an apex moment where a decision on this has To be made and this problem is now forcing a decision-maker and it's usually one person what happens is everyone's kind of it's all one team until someone has to make a decision and everyone else steps back and that person's left kind of a front category to make the decision um and they have to kind of wait things up like do they add
more cost to their counselor and the single thing that matters most to people in that situation isn't actually the Cost they'll factor it in but other biases will kind of kick in and what's actually important to them is whether or not people think they were making the right decision so they care more about what people think than what the actual cost is so you could potentially DB bias for this type of thing by you know looking at cost models kind of saying is it worth carrying on you could kind of say you know what's the
what's the value That this project is gonna deliver for us in that example if we knew that was gonna save us ten million dollars a year in effort would I carry on if it was 140 you know it's gonna be fifteen fourteen fifteen years before it repay its value probably not I'd hope not but if people think that they should carry on for political reasons like the Concord they might you know the better thing I think the D bias it is to have people who are willing to Speak up and say no like I think
you should cancel it I agree with you that if you cancel it it's making the right decision because that's the thing that affects the person's decision most so that's you know we see that a lot in kind of adult teams and people talk about that a lot and in agile teams that they're empowered that they have that capability that it's not just one person making the decision it's a team's decision and they have the support of Each other to be able to do that and really really most importantly they have the psychological safety to be
able to do that within their teams okay mm don't be gone last section so what should we remember now there's not read a lot I'm gonna cover in this because these areas are really more focused on the kind of individual the you know we do store memories differently based on how they're experienced we'll look at kind of part Of that we reduce events a list of key elements we discard specifics to form generalities and we add it and reinforce some memories after the fact you should not trust your own memory if you've talked to people
about you know something that's happened and they remember very very differently to you they're not wrong you're just both wrong and nobody's got the right memory it's all colored by our biases and by what we've kind of learned and experienced The first one I want to jump into is one that I do see a lot of negativity bias we remember the negatives far far more than the positives and if you've ever spoken and you get some negative feedback you will remember that way way more than any positive feedback that people can give you and it
just sticks out and it stays in your memory a hell of a lot longer as well and this can't in general for everything that we do we always remember the negatives from an Evolutionary kind of standpoint it kind of makes sense you know if you make a mistake add in the you know when we were cave people and it meant getting eaten by a saber-toothed tiger you know so we had to learn from the negative is much more quickly and remember than much harder than the positives and the areas that I see it in software
development are particular and things like technologies so in my example my colleague who hated xamarin forms he Really remembered the negatives of that he didn't remember that he delivered well he remembered but he didn't it wasn't at the forefront that he delivered two successful projects with it he just remembered that it was a bit painful you know and it really was just a bit painful it didn't stop them from delivering what they did need to deliver but those negative memories just stuck with him um and we do have a tendency to abandoned kind of technologies
as well Because of this focus on negativity within there and I've also seen it with M and this is quite disturbing for me as well is with people in the industry and where if someone's had a negative experience with someone in the past that they will remember that negative experience more it'll actually affect whether or not they will hire them I had an incident recently where someone said we had a potential candidate and someone in our Team said oh I worked with him before and he's not the nicest guy so that's a very kind of
broad statement to make and because there was a few years before that they'd had this incident with him it could have just been a personality clash but it was affecting this person's ability potentially to get a job so that kind of negativity bias is it's something that really we can only do bias by kind of helping each other and we're very good at spotting these biases In each other so we kind of need each other to point it out and call it and say hey maybe you're being a bit negative and someone did that in
our team and we did actually hire that guy we didn't hire him I'm sorry did we did interview that guy we didn't hire them though in the end for different reasons but that negativity is something that we need to kind of stop stop doing okay and I'm a better potentially a little bit of a can of worms for being this early in The morning a few minutes left and I want to talk about what in cognitive biases we call prejudice and this includes prejudice against sex gender age nationality ethnicity and an order grab you people
but I think it would be remiss of me to not talk about this kind of bias in a talk about biases and prejudices defined is an unfavorable feeling towards a person or thing priority or not based on actual experience and this area is really well Studied within social psychology in particular and and it kind of hangs off to things there's and there they're actually over on the other side of this and once called in-group favoritism and the other is the officer out group negativity and they're actually separated very explicitly by social psychologists because they have
different kind of affect am in-group is where we have a tendency to people within our own group and our group is Where we kind of think of people cut an outsider group we kind of give them we think of them having to have to do more to be kind of considered part of our team I guess or tribe you know and what they found there in those areas is that men tend to have actually an ethnic favoritism so given that we're in an industry dominated by white men we're probably not going to be surprised by
that and but there is a real bias there in place that we will Prefer our own kind of ethnic identity moreso than women so women are actually better at kind of accepting other ethnicities than men are and what I take from that is that by hiring more women and you'll actually kind of help to open yourself up as a team or as an organization to more ethnicities within there and that mentality will and move through the team as well help them to kind of form that information and interesting that the women actually have A strong
gender bias for that in-group favoritism more so than men it's like 4.5 times stronger than man so women will prefer to to stay with other women 4.5 times more than the men will stay to prefer with kind of other men and the effect that I've seen that have is that when you are trying to hire women when you were trying to improve your gender diversity within your organization unless you already have women there it's very very difficult to convince them to Come on um I'm lucky in that I have a Donna Edwards whose talk is
to stand for me you should go listen to it about building better teams and she was able to help build that and I'd highly recommend that you go listen to that talk if that is an area that you were that you need help with him cool em but yeah I guess the the kind of point of this I guess from the reason why I wanted to talk about this prejudice is That I do really really think and I hope you've kind of gathered from the previous stuff that I've talked through that the best way to
deep eye is for a lot of these things is to have that kind of diversity of gender to have that kind of diversity of ethnicity and background and even diversity of thought because that's really the only way that we're all gonna get better at this so that completes our little trek around the codex i hope it's Given you some insight and i hope you're inspired to investigate more in it you can google this cognitive bias codex you if you grab the SVG they all actually link through to the relevant wikipedia article and you can investigate
it more there i would caution you though as with any knowledge just be careful of it you know make sure you understand it remember the dunning-kruger effect before you go accusing your boss of illusory superiority but if you do Investigate you do have any stories that you think would be interesting I'd love to hear them my contact details again and with my LinkedIn at the at the bottom there and I do have stickers down here lots of stickers there's a no-drama llama and corns having a beer so if you want to grab them feel feel
free and come ask me any questions or ping me on that thank you all very much your time have a great day [Applause]
