Software Development: Fast and Slow.

This content is syndicated from Edge of Chaos | Agile Development Blog by Michael Dubakov. To view the original post in full, click here.

How to use ideas from the great book by Daniel Kahneman Thinking, Fast and Slow.

Recently I read a fascinating book by Daniel Kahneman Thinking, Fast and Slow. It has tons of insights. Every chapter was a discovery. I learned so many new things.

I work in a software development company. It’s quite natural to apply new learned things to your domain. That’s what I’m doing in this post.

System 1 and System 2

The book is about two systems in the human brain. System 1 is fast, intuitive, alert and cheap. System 2 is lazy, analytical and expensive. Most daily activities and tasks are solved by System 1, while the most complex tasks are redirected to System 2.

When you use System 1 you feel nothing. It’s natural and effortless. When you use System 2, you feel strain and pressure. You notice that you are really thinking hard. System 2 is effortful.

There are many experiments that proves existence of these two systems. Make no mistake, there is no clear separation of these systems on a physical brain structure, but they describe how people think and make decisions.

If you are a software engineer, you’ll immediately grasp the nature of System 1 and System 2. System 1 is quite similar to cache, while System 2 is a business layer. Cache is cheap and fast, business opearation is slow and expensive.

Now I’ll take first concepts from the book and find examples in software development.

What You See Is All There Is (WYSIATI)

People usually don’t think about things they don’t see (in a broad sense). If you have some information, it’s unlikely that you’ll immediately question it and go look for some alternatives. Quite often people make decisions based on existing facts and limited evidence. This leads to several biases:

Estimation is not easy in software development. We make huge mistakes all the time. Estimation is a distribution.


Software estimation is the area where overconfidence flourishes.

“We need twitter integration — you ask — We want to accumulate all tweets with specific tags. When you can complete this?” Developers often don’t ask additional questions and just provide quick estimate like, well, 2 days. This is System 1 in action. It’s extremely unlikely the answer is correct. Lack of information somehow doesn’t impede immediate estimate. Developers should be smart and confident, oh yes! But also they should escape WYSIATI and think carefully about unknowns.

Framing Effect

Problem wording does matter. If you describe the same problem using different words you can have different solutions or preferences. Consider two questions:

  • “Do you think we need a very experienced developer to solve this simple problem?”
  • “Do you think we need a very experienced developer to solve this complex problem?”

The question set the frame. It’s hard to answer “Yes” to the first question, it’s easy to answer “Yes” to the second one.

Base-rate Neglect

Some events are more likely than others. However, people have no good intuition about statistics.

Let’s say, you create a product that used by 1000 companies. You receive an email from a customer who think that his idea is really “must have” and should be implemented ASAP. The argumentation is perfect and does make real sense. You feel his pain and push this new feature to production with all your force. Well, you missed one thing: it may very well happen that 999 other customers have no need in this solution. You forget that customers base is large and a single request should be reviewed from that perspective.

It’s a very common mistake and I repeated it again and again myself. Now I know better and think very carefully about every request. No rush. In rush you delegate the decision to System 1, and this system do you no good in such a complex domain.

Answering an easier question

When we encounter a hard question, we tend to replace it in our mind with an easy one, that System 1 can handle. Here is an example.

You hear the question “How good will be progress on this project 3 months from now?” You replace this tricky question with “How good is progress right now?”

By doing this substitution, you don’t awake your lazy System 2 and allow System 1 to answer the easier question. We follow the path of least effort. The funny thing is that we don’t realize the substitution, we really think we answered the hard question!

Affect heuristic

If we like something or dislike something it affects our decisions greatly. For example, if you like node.js, you will be optimistic about choosing node.js for the new web application. If you hate node.js, you will provide so many arguments against it and will fight to death to apply another technology.

The affect heuristic is hard to overcome. People are not so rational, but clearly some reasonable comparison of technologies will be much better than a quick choice based on intuitive preferences.

I just scratches the surface, but it’s already obvious that our decisions in software development based on many biases and bad heuristics. What can we do about it?

Intuition vs. Models

Kahneman was very skeptical about our abilities to wake up System 2 when it’s really needed. Indeed, how can we change a human nature?

However, it seems we can do something. We can apply models.

Kano Model is a good example. It helps to make more intelligent decisions about new features.

Model is almost always better than intuition. Even a very simple linear model is better than most (all?) experts in a domain. Model forces you to think about the domain, about various facets of the problem, look at it from different angles — use System 2.

Here is the simple question: What feature should we start next? You can rely on your intuition and say “Advanced Search”. It may happen that this feature is not so important and there are dozen of more important features. You can build a simple model and evaluate your backlog. For example, the model can have parameters like:

  1. Kano model (basic, delighter, performance)
  2. Votes: How many customers and leads requested it
  3. Frequency: how often people will use this feature.
  4. Spread: how many people will use the feature.
  5. Effort (S, M, L, XL, …)
  6. Complexity. Will it increase usage complexity

With this simple model you’ll make much better decision for sure.

I believe models can be applied to many areas in software development. Decision making and problem solving should rarely rely on intuition, unless you are Steve Jobs.

Leave a Reply

What is 3 + 7 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”