Sense-driven Development
Tags: psychology, development
Published: 2017-10-07 09:15:27

---
title: "Sense-driven Development"
published: true
description: How to develop with sensibility.
tags: psychology, development, meta
cover_image: https://thepracticaldev.s3.amazonaws.com/i/1xl2gderwktsm8oulu4f.jpeg
---

One of the people who taught me a lot of what I know right now as a developer is our former TestLab team lead [Czar Pino](https://medium.com/@czarpino). Sometimes when he’s making a decision or when he’s explaining something, he would ask, *“does this make sense?”*.
I believe this is a great way of thinking about things. When we’re developing softwareâ€Š–â€Šor doing anything actuallyâ€Š–â€Šwe should always ask ourselves, *“does this make sense?”*. When we make decisions, they should always be sensible ones.

> Sensible: (of a statement or course of action) chosen in accordance with wisdom or prudence; likely to be of benefit. (Google.com, 2017)

## “duh, that’s obvious”
![no shit](https://thepracticaldev.s3.amazonaws.com/i/5opcy7i7cc06zt0d8vce.gif)

You might be thinking that it’s obvious and all but we often make decisions that don’t make a lot of sense or don’t make any sense at all. This is all because of our brains and what we call [cognitive bias](https://www.wikiwand.com/en/Cognitive_bias), which isâ€Š–â€Šas the name suggestsâ€Š–â€Ša bias in the way we think. An example of that is the [confirmation bias](https://www.wikiwand.com/en/Confirmation_bias), wherein we tend to look for evidences to confirm what we like or what we already know. I highly recommend looking at this [list of cognitive biases](https://www.scribd.com/doc/30548590/Cognitive-Biases-A-Visual-Study-Guide) for reference.

Why does this happen? This is because our brain is efficient. Sound counterintuitive? I know, right? It becomes efficient by making shortcuts and these shortcuts lead to these cognitive biases. These shortcuts were very relevant in the past when we were still carnivorous, cave-dwellersâ€Š–â€Šand I still am, actually (loljk)â€Š–â€Šbecause we have to make snap decisions when we were about to get gangbanged and ripped to shreds by a pride of sabertooth kitties. These brain shortcuts were relevant back then. Now, not so much. This is the “**Thinking Fast**” or “**System 1**” part of Daniel Kahneman’s theory in his book *Thinking Fast and Slow*.
Nowadays we need to learn to think slowlyâ€Š–â€Šbe more calculating and take the time to make decisions. That way, we have a better chance of avoiding cognitive biases. Another way to reduce cognitive cognitive biases is to get trusted people to assess us and our decisions. We all have cognitive biases against other people too like the Fundamental Attribution Error, but at least there two minds instead of just one and you can be honest with each other.
Yet Anotherâ„¢ ï¸way of reducing cognitive is to ask the question, “does this make sense?”.

## A Chain Reaction
This question is the first step to the **process of thinking about our thinking processes**. That sounds really meta and it is but that makes it great. That question spurs a lot of other questions like:

- Why wouldn’t that make sense? (The weak points)
- Why does it make sense? (The strong points)
- Why did I make that decision? (Reasons and conditions behind that line of thought)
- How did I arrive at that decision? (The thoughts that lead up to that decision)
- Is it overkill? (Premature optimization)
- Do I really need it? (Minimalism)
- Is there a better way? (Better possibilities)
- What are the costs of this decision? (Well, the costs)
- Did other people understand what I just said? (Clarity of explanation)
- Will a 5-year old be able to understand it? (If it can’t, you don’t know the topic well enough)

and others like that. The question starts a chain reaction of questions that will help you validate or invalidate that decisionâ€Š–â€Što see whether it was actually made “*in accordance with wisdom or prudence*”.

Let’s try to put this into context.

## Scenario: Building your tech stack
(This is opinionated so please don’t kill me.)

Imagine you’re a small company building a music app. You need to be able to build your prototype in 2 months. Your tech lead decides that you’re going to use the following stack:

1. API: **GraphQL on Go**
2. Web Frontend: **Inferno & Redux**
3. Mobile: **Flutter**
4. Database: **MySQL**

What your team knows:

1. REST
2. PHP (**Laravel**)
3. Javascript (**Node.js, Meteor, React & Redux**)
4. **MongoDB**
5. **MySQL**

You start to get overwhelmed with everything you see here. Now would be a good time to ask the question, “does this make sense?”. Let’s walk through this and let’s find out.

### API
> **Does it make sense** to use GraphQL over REST?

Well, it helps conserve bandwidth and it’s easier for the consumers of the API to use than REST.

> **Why wouldn’t** using GraphQL over REST make sense?

The team knows REST. They may be familiar with GraphQL but they don’t know how to implement it.

> **Does it make sense** to use Go over PHP or Node?

Go is faster than PHP or Node because it is low-level and has great support for concurrency.

> **Why wouldn’t** using Go over PHP or Node make sense?

You only have two months to build the prototype. None of your developers know Go or C (which is also low-level). You don’t know if the boost in performance is worth it when compared to the development time.

### Web Frontend
> **Does it make sense** to use Inferno?

Well, your team knows React and Inferno and there isn’t a lot of difference so the development time wouldn’t really be that much different. Except that Inferno is usually faster than React. The question is: do you really need that speed? Do you really need to squeeze every last drop of speed? The answer is up to you.

> How about React 16?

That’s another thing to think about. React apparently got faster because of the new Fiber architecture. It’s up to you. If the performance boost really matters, maybe you can check if Inferno has a significant advantage in speed vs. React 16. If not, maybe you should stick to React because the developers already have experience using it.

> **Does it make sense** to use Redux?

Your team already knows Redux. Use Redux.

> **Why wouldn’t** it make sense to use Redux?

Is it gonna be a huge app? Will it have a lot of moving parts? If yes, it’s a good bet to use Redux. Also, if your team is into **functional programming**, Redux is a good fit in that paradigm. If it’s not gonna be a huge app or if you’re sure every member of your team will write clean code, you can use MobX. MobX is also a good bet if you prefer the **Object-Oriented paradigm** over the **Functional paradigm**. Better yet, don’t use a state management library at all. For a prototype, maybe you can try MobX, but think about the future: will the app significantly more complicated than it is now? If not, maybe you can continue using MobX or maybe drop it altogether. If it will be more complicated, use Redux from the get-go.

### Mobile
> **Does it make sense** to use Flutter?

No, it doesn’t. You don’t have time to learn Dart. Use **React Native** or **Cordova** instead because your team already knows React.

### Database
> **Does it make sense** to use MySQL?

Your team knows MySQL. It will make it easier for you and your teammates to develop your prototype because you’re already used to it.

> **Why doesn’t it make sense** to use MySQL?

Your app might have big data in the future. If that is the case maybe MongoDB is a better fit.

## De Bono’s Six Thinking Hats
Dr. Edward de Bono created a system of six different types of thinking which he calls the [six thinking hats](http://www.debonogroup.com/six_thinking_hats.php). 
The thinking hats are the following:

> The **White Hat** calls for **information known or needed**. “The facts, just the facts.”
> The **Yellow Hat** symbolizes **brightness and optimism**. Under this hat you explore the positives and probe for value and benefit.
> The **Black Hat** is judgmentâ€Š–â€Šthe devil’s advocate or why something may not work. Spot the difficulties and dangers; **where things might go wrong**. Probably the most powerful and useful of the Hats but a problem if overused.
> The **Red Hat** signifies feelings, hunches and intuition. When using this hat you can express **emotions and feelings** and share fears, likes, dislikes, loves, and hates.
> The **Green Hat** focuses on creativity; the **possibilities, alternatives, and new ideas**. It’s an opportunity to express new concepts and new perceptions.
> The **Blue Hat** is used to manage the thinking process. It’s the **control mechanism** that ensures the Six Thinking HatsÂ® guidelines are observed.

For example, you can begin by wearing the White Hat and think about the hard facts and the strict requirements. You can then wear the Green Hat and go crazy and come up with new ideas. After that, you can “wear” the Yellow Hat to explore the best parts of a certain idea and the “nice-to-haves”, then “wear” the Black Hat and think about everything that can go wrong with it.

I think this is a pretty effective way of system of thinking because tend to stick with just one or two thinking hats. This system gives us the opportunity to break out of our usual thinking modes.

## Conclusion

When making decisions you can try these:

- Always think about the decisions you’re making
- Make sure they’re informed decisions
- Make sure you do your research
- Make sure to ask yourself relevant questions
- Make sure to ask your teammates relevant questions
- Always check other perspectives (try other thinking hats)
- Ask yourself, “does this make sense?”

That’s it! I hope this helped you make better decisions. Don’t worry, everyone makes bad decisions. I’m no exception. We can just get better at making good decisions.

> This article was originally posted on [Medium](https://medium.com/programmers-developers/sense-driven-development-1789a784eb16).