Programming, fast and slow: developers and psychology of overconfidence
Today I'm going to talk about what's going on in the minds of software developers, at a time when they're doing preliminary calculations; about why they are so hard to capture all the ideas in his head; and how I personally have allowed this situation, learned how to live and write (happy business owners), but I'm sure my own assessment of the complexity unreliable as ever.
But first the story...
It was <insert time period that will not make me ridiculous old> at a time when I was a young developer (1). In College, I was the best in the classroom programming as a Junior developer, I was able to crack the code and solve any set me the task faster than anyone expected. Over the weekend I was able to learn a new language and productive to work on it (or at least so I thought).
Thus, as was supposed to happen, I had my own project. Manager to work with major clients explained to me in General terms what the client wants, we discussed it, and I said, "this work will take 3 weeks." "Well," he said. And so I started programming.
What do you think how much time I spent on this project? Four weeks? Maybe five?
Mm, actually three months.
I was left with clear memories of that time – my idea of myself was closely associated with the feeling, that I'm a "good programmer", which I was very disappointed. I lost sleep, I have had a few minor panic attacks. And this Was Not the End. I remember that I suck in the stomach when speaking with the Manager, I again and again explained that I still have no anything to show him.
In one of these black periods, I decided that I Will Never Make Such Mistakes.
Unfortunately, in the course of his career, I have learned something very difficult: I always make mistakes like that.
Actually, I did something better: we all make these mistakes.
Recently, I read a book by Daniel Kahneman "Thinking, Fast and Slow" — an extensive study of what is known of the psychology of cognitive processes of man, of his amazing strengths, and (surprisingly predictable) weakness.
My favorite part concerns self-Confidence. It was shown, say, some connection with how the developers make the calculations.
For starters, I believe that in reality, there are only two reasons why our estimates are so bad. The first reason sort of not amenable to improvement: writing is a process in which you need to figure out how to describe something in incredibly accurate detail, in order to be able to explain to the computer how it should be done. But the problem is that in those parts you do not fully understand at the initial stage of the work, and hiding the complexity that will come out hard and you will get raped.
And it absolutely cannot be improved in any way. And only if you do "fully understand what to do", or you have a library, or is there a part that can do it for you, then you write nothing. Otherwise, there is the unknown, and often it detonates. And the solution of these problems you may take who knows how long, maybe one day, one year or you may not have enough time until the heat death of the universe.
For example, in the case where it turns out that some outsourced developments, unreliable... then you have to rewrite the whole array, containing the error; or when the database does not understand some critical parts of coding, then you have to rebuild all of your scheme; or, a real classic of the genre, when you show work to clients, and they do not receive what you ordered for yourself, and want some other... the fact that significantly more difficult to do.
When you first encounter such a difficulty, that you think "should Continue to be more attentive under development specifications". But it's not a good idea. Why? The main reason is that, as seen from the above examples, if you draw up a specification so detailed that take into account all these eventualities, it really appears that you have written. And, indeed, there is no way to solve this problem (if reading this article, you are trying to challenge this claim, I will tell you – precisely, exactly, there is no way. The full specification is utopian economic idea. Below I will show you more beneficial from an economic point of view, options).
But here's where the fun begins. Every programmer who has worked in the real world more than a couple of months, faced with the above problems.
And yet... we continue to do such impressive bad calculations.
And what's worse, we believe our own estimates. I believe, in that moment, when I produce them.
So, wait, am I suggesting that all developers somehow became a victim of the same, predictable errors in thinking?
Yes, that's exactly what I propose.
Kahneman says quite a lot about the problem of "experts" making predictions. In a shockingly wide variety of situations, these forecasts are completely useless. In particular, many situations retain the validity of the following three statements:
1 - Predictions of "experts" on any future events so unreliable that essentially meaningless.
2 - However, the experts are incredibly confident in the accuracy of their forecasts;
3 - And best of all: it seems that absolutely nothing can diminish the feeling of self-confidence of experts;
And the last statement is truly remarkable, that, even if experts try to honestly face our own failures, even if they are aware of this flaw of human thinking..., they nevertheless remain deeply confident in the accuracy of its forecasts.
Here's how Kahneman explains it, after the story amazing stories about their own failures in this field:
"The confidence you will feel in your future judgments will not be diminished by the fact that you just read, even if you believe every word."
Interestingly, there are situations for which expert predictions are pretty good, and I'm going to demonstrate below these situations, and how to use them to improve their processes for the design. But before I do that, I'd like to go over some details of how the erroneous presumption, in practice, you may be able to detect it in yourself.
In "Thinking Fast and Slow", Kahneman explains a large part of psychology as the interaction between the two "systems" that govern our thoughts: the System I and System II. My very short summary about it is: "System II is responsible for careful, rational, analytical thinking, and System I is responsible for quick-thinking, heuristic and comparative".
And critical is that evolution like all designed with a single purpose – to System II not had to do too much. That is a very logical from the point of view of evolution – System II is slow as molasses, and incredibly expensive, it must be applied in very rare cases. But you see the problem, no doubt, without much thinking, as your mind needs to understand when to start the System II? From this point of view, many of the various "cognitive distortions" of psychology can be perceived as sophisticated engineering solutions to such a cruel life issue, as the distribution of attention in real time.
To see how the interaction of Systems I and II can lead to really terrible, and at the same time honestly trusting to the calculations, I'm going to give the microphone briefly to his friend (and colleague Hut8Labs) Edmund Argentino (Edmund Jorgensen). He described this to me in his letter as follows:
"When I asked myself "how much time will be spent on this project" I had no idea about this, but wanted to get the answer and recode them question. What? I suspect that in something like "how confident I am that I can do this thing," and this, in turn, were recoded to calculate time with a certain coefficient, which is a relative value (for example, when Bob feels a degree of confidence X, then he is 3 weeks; when Susie feels a degree of confidence X, then she's 5 weeks)."
Raise your hand if you realized that you have two "big" time gauges? For example, for me it's "3 weeks" and "3 months". The first implies that "it looks complicated, but in essence I think I know how to do it"; the second means: "Wow, it's hard, I'm not quite sure what you need, but I bet I can figure it out".
Aha, I think Edmund is completely correct.
(For those who are stalling home: my "3 week" projects seem to take 5-15 weeks, my "3 month" projects typically take 1-3 years, on those rare occasions when someone wants me to pay for it).
You might think c's point of view: "Okay, I see your point, Dan, we need to approach these calculations in accordance with the principles of the System II instead of System I. Thus, our careful, analytical minds will make the best calculations."
Congratulations, you just invented the Waterfall.
Essentially, this approach of "preparation of detailed specifications prior to programming": don't let your team to make intuitive calculations, make all neatly, to mobilize their analytical skills and to approach the issue with a detailed specification and calculations, broken into smaller pieces.
However, this is doomed to failure. As usual...
The real problem here is the interaction between the two sources of erroneous measurements: human error in relation to their self-confidence, and an integral element of uncertainty, inherent in every real writing project. This uncertainty is so severe that even careful rational System II is not able to provide accurate predictions.
Fortunately, there is a way to combine the strengths of thinking, and at the same time, to cope with the intermittency of the real world.
First, how to use the strengths of his thinking.
Kahneman and other researchers were able to identify a situation when the experts ' judgement is not completely wrong. In his words:
"To find out if you can trust a particular intuitive judgment, it is necessary to ask two questions: Is the environment in which there is a judgment, reasonably constant for the adoption of projections based on the available evidence? The answer is "Yes" to the Diagnostician, "no" — for the stock-picker. Do professionals the opportunity to study the signals and patterns?"
"Relevant opportunity" means a large number of perfect forecasts, as well as a strong feedback to explore their accuracy.
Now, 6-18 month projects writing absolutely do not meet all these criteria. As I said earlier, the environment is not quite "permanent". In addition, experts do not have the combination to make many predictions and get quick feedback. If something requires a year or more, then the feedback is too long for the training of intuition (plus, you'll need a large number of examples).
However, there is a form of accounts applicable to software development, which is suitable – 0-12 hour tasks, if they are then immediately implemented. From this angle, things work differently:
the
From this point of view, you use the strengths of System I to have the opportunity to train, she has a lot of examples and meaningful models that you can choose. And due to the short intervals of sprints, you very quickly get feedback on the quality of your calculations.
How can I claim that you can produce these micro calculations, but somehow can't apply them to 6-18 month calculations? Except error values averaged?
Essentially, although I think that the calculations of this magnitude are usually correct in the case when they are not correct, there is simply no limit to how much they can be incorrect. In mathematical terms, I suspect the actual times follow a power-law distribution. And distribution power-law is known not to have stable value and infinite variance, which, frankly, seem to me to be the same calculations of the project a large waterfall.
You may be thinking, how is it possible that something that you can do in 4 hours might take a month or two?
It happens all the time: are you going to move to the final stage, but suddenly learn that some hidden obstacles radically change everything. For example, in a recent startup when trying to eliminate certain errors in the system, we went to put a load balancer in front of the IMAP server that we wrote. So that when one server goes down, the load balancer seamlessly moved the process to another, and customers didn't feel anything.
And this seemed like a 4 hour task.
But when we arrived, we realized/remembered that the IMAP server uses the connection status, unlike HTTP servers, to which we are accustomed. So, if we want to switch to the backup server was in transparent mode, we will have to manage a connection state between two servers or to write a semblance of a proxy load balancer, which would be responsible for the status of the connection and was mounted in front of an IMAP server.
What seemed like a 3-month project (2).
Here is one of the reasons that short sprints are the key to all this: they put a hard limit on the price of a terrible miscalculation.
So what are we to do? To accept the fact that all our projects are doomed to failure; that we will spoil the relationship with other clients, due to the fact that you can't fulfil our promises?
The solution is to first accept the fact that to make accurate long-term calculations is fundamentally impossible. As soon as you realize you can be on to the next task, which, however, are quite difficult to handle: how can you make your team of developers to produce tons of value, even though you can't produce more or less significant long-term calculations.
What we have here is essentially a first principles explanation for why the world has adopted various Flexible software development methodologies. More in detail I will tell about it in following topic: "the timing of Delivery of Projects There! How To Make Customers Love You, Even Though You Do Not Fulfill Their Obligations."
1. (group <insert a dated music reference> played on the radio, and all are discussed <a long-forgotten TV show>.
2. If you think, "Wait, what about 3 months as one of your 3 monthly payments?", I have no idea what you're talking about.
the Translation is done in the framework of the summer school startups Tolstoy Summer Camp
Article based on information from habrahabr.ru
But first the story...
It was <insert time period that will not make me ridiculous old> at a time when I was a young developer (1). In College, I was the best in the classroom programming as a Junior developer, I was able to crack the code and solve any set me the task faster than anyone expected. Over the weekend I was able to learn a new language and productive to work on it (or at least so I thought).
Thus, as was supposed to happen, I had my own project. Manager to work with major clients explained to me in General terms what the client wants, we discussed it, and I said, "this work will take 3 weeks." "Well," he said. And so I started programming.
What do you think how much time I spent on this project? Four weeks? Maybe five?
Mm, actually three months.
I was left with clear memories of that time – my idea of myself was closely associated with the feeling, that I'm a "good programmer", which I was very disappointed. I lost sleep, I have had a few minor panic attacks. And this Was Not the End. I remember that I suck in the stomach when speaking with the Manager, I again and again explained that I still have no anything to show him.
In one of these black periods, I decided that I Will Never Make Such Mistakes.
Unfortunately, in the course of his career, I have learned something very difficult: I always make mistakes like that.
Actually, I did something better: we all make these mistakes.
Recently, I read a book by Daniel Kahneman "Thinking, Fast and Slow" — an extensive study of what is known of the psychology of cognitive processes of man, of his amazing strengths, and (surprisingly predictable) weakness.
My favorite part concerns self-Confidence. It was shown, say, some connection with how the developers make the calculations.
Why your calculations suck, part I: writing SOFTWARE = knowledge of something you don't know
For starters, I believe that in reality, there are only two reasons why our estimates are so bad. The first reason sort of not amenable to improvement: writing is a process in which you need to figure out how to describe something in incredibly accurate detail, in order to be able to explain to the computer how it should be done. But the problem is that in those parts you do not fully understand at the initial stage of the work, and hiding the complexity that will come out hard and you will get raped.
And it absolutely cannot be improved in any way. And only if you do "fully understand what to do", or you have a library, or is there a part that can do it for you, then you write nothing. Otherwise, there is the unknown, and often it detonates. And the solution of these problems you may take who knows how long, maybe one day, one year or you may not have enough time until the heat death of the universe.
For example, in the case where it turns out that some outsourced developments, unreliable... then you have to rewrite the whole array, containing the error; or when the database does not understand some critical parts of coding, then you have to rebuild all of your scheme; or, a real classic of the genre, when you show work to clients, and they do not receive what you ordered for yourself, and want some other... the fact that significantly more difficult to do.
When you first encounter such a difficulty, that you think "should Continue to be more attentive under development specifications". But it's not a good idea. Why? The main reason is that, as seen from the above examples, if you draw up a specification so detailed that take into account all these eventualities, it really appears that you have written. And, indeed, there is no way to solve this problem (if reading this article, you are trying to challenge this claim, I will tell you – precisely, exactly, there is no way. The full specification is utopian economic idea. Below I will show you more beneficial from an economic point of view, options).
But here's where the fun begins. Every programmer who has worked in the real world more than a couple of months, faced with the above problems.
And yet... we continue to do such impressive bad calculations.
And what's worse, we believe our own estimates. I believe, in that moment, when I produce them.
So, wait, am I suggesting that all developers somehow became a victim of the same, predictable errors in thinking?
Yes, that's exactly what I propose.
Why your calculations suck, part II: self-confidence
Kahneman says quite a lot about the problem of "experts" making predictions. In a shockingly wide variety of situations, these forecasts are completely useless. In particular, many situations retain the validity of the following three statements:
1 - Predictions of "experts" on any future events so unreliable that essentially meaningless.
2 - However, the experts are incredibly confident in the accuracy of their forecasts;
3 - And best of all: it seems that absolutely nothing can diminish the feeling of self-confidence of experts;
And the last statement is truly remarkable, that, even if experts try to honestly face our own failures, even if they are aware of this flaw of human thinking..., they nevertheless remain deeply confident in the accuracy of its forecasts.
Here's how Kahneman explains it, after the story amazing stories about their own failures in this field:
"The confidence you will feel in your future judgments will not be diminished by the fact that you just read, even if you believe every word."
Interestingly, there are situations for which expert predictions are pretty good, and I'm going to demonstrate below these situations, and how to use them to improve their processes for the design. But before I do that, I'd like to go over some details of how the erroneous presumption, in practice, you may be able to detect it in yourself.
How does it feel that you are wrong: systems I and II, and issue 3-weeks and 3-months
In "Thinking Fast and Slow", Kahneman explains a large part of psychology as the interaction between the two "systems" that govern our thoughts: the System I and System II. My very short summary about it is: "System II is responsible for careful, rational, analytical thinking, and System I is responsible for quick-thinking, heuristic and comparative".
And critical is that evolution like all designed with a single purpose – to System II not had to do too much. That is a very logical from the point of view of evolution – System II is slow as molasses, and incredibly expensive, it must be applied in very rare cases. But you see the problem, no doubt, without much thinking, as your mind needs to understand when to start the System II? From this point of view, many of the various "cognitive distortions" of psychology can be perceived as sophisticated engineering solutions to such a cruel life issue, as the distribution of attention in real time.
To see how the interaction of Systems I and II can lead to really terrible, and at the same time honestly trusting to the calculations, I'm going to give the microphone briefly to his friend (and colleague Hut8Labs) Edmund Argentino (Edmund Jorgensen). He described this to me in his letter as follows:
"When I asked myself "how much time will be spent on this project" I had no idea about this, but wanted to get the answer and recode them question. What? I suspect that in something like "how confident I am that I can do this thing," and this, in turn, were recoded to calculate time with a certain coefficient, which is a relative value (for example, when Bob feels a degree of confidence X, then he is 3 weeks; when Susie feels a degree of confidence X, then she's 5 weeks)."
Raise your hand if you realized that you have two "big" time gauges? For example, for me it's "3 weeks" and "3 months". The first implies that "it looks complicated, but in essence I think I know how to do it"; the second means: "Wow, it's hard, I'm not quite sure what you need, but I bet I can figure it out".
Aha, I think Edmund is completely correct.
(For those who are stalling home: my "3 week" projects seem to take 5-15 weeks, my "3 month" projects typically take 1-3 years, on those rare occasions when someone wants me to pay for it).
Great! Now let's stop being so arrogant!
You might think c's point of view: "Okay, I see your point, Dan, we need to approach these calculations in accordance with the principles of the System II instead of System I. Thus, our careful, analytical minds will make the best calculations."
Congratulations, you just invented the Waterfall.
Essentially, this approach of "preparation of detailed specifications prior to programming": don't let your team to make intuitive calculations, make all neatly, to mobilize their analytical skills and to approach the issue with a detailed specification and calculations, broken into smaller pieces.
However, this is doomed to failure. As usual...
The real problem here is the interaction between the two sources of erroneous measurements: human error in relation to their self-confidence, and an integral element of uncertainty, inherent in every real writing project. This uncertainty is so severe that even careful rational System II is not able to provide accurate predictions.
Fortunately, there is a way to combine the strengths of thinking, and at the same time, to cope with the intermittency of the real world.
First, how to use the strengths of his thinking.
When the experts are right, and how to use
Kahneman and other researchers were able to identify a situation when the experts ' judgement is not completely wrong. In his words:
"To find out if you can trust a particular intuitive judgment, it is necessary to ask two questions: Is the environment in which there is a judgment, reasonably constant for the adoption of projections based on the available evidence? The answer is "Yes" to the Diagnostician, "no" — for the stock-picker. Do professionals the opportunity to study the signals and patterns?"
"Relevant opportunity" means a large number of perfect forecasts, as well as a strong feedback to explore their accuracy.
Now, 6-18 month projects writing absolutely do not meet all these criteria. As I said earlier, the environment is not quite "permanent". In addition, experts do not have the combination to make many predictions and get quick feedback. If something requires a year or more, then the feedback is too long for the training of intuition (plus, you'll need a large number of examples).
However, there is a form of accounts applicable to software development, which is suitable – 0-12 hour tasks, if they are then immediately implemented. From this angle, things work differently:
the
- You can assume to make hundreds of such calculations, for several years; the
- You get very fast feedback about the accuracy of the calculations.
Although still a lot of accidents (more on that below), there remains the hope of "consistency of environment". Two two-hour tasks have more in common than two six-month project; the
From this point of view, you use the strengths of System I to have the opportunity to train, she has a lot of examples and meaningful models that you can choose. And due to the short intervals of sprints, you very quickly get feedback on the quality of your calculations.
stop, stop, Stop! Let's just make a thousand 4 hour calculations!
How can I claim that you can produce these micro calculations, but somehow can't apply them to 6-18 month calculations? Except error values averaged?
Essentially, although I think that the calculations of this magnitude are usually correct in the case when they are not correct, there is simply no limit to how much they can be incorrect. In mathematical terms, I suspect the actual times follow a power-law distribution. And distribution power-law is known not to have stable value and infinite variance, which, frankly, seem to me to be the same calculations of the project a large waterfall.
You may be thinking, how is it possible that something that you can do in 4 hours might take a month or two?
It happens all the time: are you going to move to the final stage, but suddenly learn that some hidden obstacles radically change everything. For example, in a recent startup when trying to eliminate certain errors in the system, we went to put a load balancer in front of the IMAP server that we wrote. So that when one server goes down, the load balancer seamlessly moved the process to another, and customers didn't feel anything.
And this seemed like a 4 hour task.
But when we arrived, we realized/remembered that the IMAP server uses the connection status, unlike HTTP servers, to which we are accustomed. So, if we want to switch to the backup server was in transparent mode, we will have to manage a connection state between two servers or to write a semblance of a proxy load balancer, which would be responsible for the status of the connection and was mounted in front of an IMAP server.
What seemed like a 3-month project (2).
Here is one of the reasons that short sprints are the key to all this: they put a hard limit on the price of a terrible miscalculation.
We're?
So what are we to do? To accept the fact that all our projects are doomed to failure; that we will spoil the relationship with other clients, due to the fact that you can't fulfil our promises?
The solution is to first accept the fact that to make accurate long-term calculations is fundamentally impossible. As soon as you realize you can be on to the next task, which, however, are quite difficult to handle: how can you make your team of developers to produce tons of value, even though you can't produce more or less significant long-term calculations.
What we have here is essentially a first principles explanation for why the world has adopted various Flexible software development methodologies. More in detail I will tell about it in following topic: "the timing of Delivery of Projects There! How To Make Customers Love You, Even Though You Do Not Fulfill Their Obligations."
1. (group <insert a dated music reference> played on the radio, and all are discussed <a long-forgotten TV show>.
2. If you think, "Wait, what about 3 months as one of your 3 monthly payments?", I have no idea what you're talking about.
the Translation is done in the framework of the summer school startups Tolstoy Summer Camp
Комментарии
Отправить комментарий