In the last few years, I started to love boring technologies. It’s most likely connected to my age, and many projects started with bleeding-edge technologies following the hype. Usually, in the initial brainstorming meetings, I’m the grumpy guy that exclaims: “Do we really need GraphQL, a boring REST API is not enough?”.

Obviously, younger teammates are generally mad at me. They see me as a buzzkill.

Nevertheless, I do the same work with my clients and not just with my colleagues. I frequently help them in choosing technology stacks. While I’m quite good at demystifying Hype when choosing technologies for a greenfield product, I usually feel puzzled when a team has the opposite approach: walking the usual path.

This is the typical conversation I have with teams affected by The Usual Path.

2010
Me: What Framework should we use for this new project?
Client: AngularJS!
Me: It’s a bit new, but ok! Let’s try it

---

2013
Me: What Framework should we use for this new project?
Client: AngularJS!
Me: It’s quite mainstream now, and you have a lot of experienced developers that are quite skilled with it. I think it’s a good idea.

---

2017
Me: What Framework should we use for this new project?
Client: AngularJS!
Me: You Know, Angular 2 is out now. Perhaps you should consider it?
Client: It’s not the right project to learn new technologies. Next time, perhaps…

---

2022
Me: What Framework should we use for this new project?
Client: AngularJS!
Me: I think it’s a really bad idea, the LTS is over.
Client: I know, but we don’t have time! We have a very strict deadline! Let’s go build some directives now!

This conversation never happened, but I can assure you that something similar happened to me quite often in these years as a consultant, trying to help developer teams in making mindful decisions.

Some years ago, I collaborated with a company that built all their core products with Visual FoxPro. They were real experts in Visual FoxPro, and over the years, they became better and better. But they fall victim to the Golden Hammer law:

If all you have is a hammer, everything looks like a nail

When Microsoft announced that Visual FoxPro would not be supported anymore, they started to realize their situation. They panicked and started to think about how to survive. One of the proposals that emerged during that time was to give their customers laptops with Windows XP in a bundle with their software to prevent users from upgrading. I really don’t know how they solved it; I just stopped collaborating with them. But that story still haunts me.

At that time, I felt it was entirely a technical problem; people were too lazy to study new stuff and fell behind. But now I know that this is just the tip of the Iceberg. So, whenever I feel that a team is walking the Usual Path, I ask questions. I want to know the root cause of their reluctance.

It’s a “People” problem

Developers are not “lazy”, but they can become “lazy” if they work in an environment that becomes toxic for innovation. I observed two main factors that usually lead to the Usual Path.

The first one is related to the power structure of a company. I observed that when people are afraid of trying something new, the real thing that people are afraid of is the consequences of failure. If you constantly fear that your team will be blamed for missing a deadline, you will choose to remain in your comfort zone. Because it’s easier to defend yourself if you say:

“We tried our best not to miss the deadline, we used a tech stack that we know very well”

*Unfortunately, when the blaming culture takes root, it is very hard to remove. **It takes a lot of effort and the will of every person involved, from developers to C-level. Sadly, most of the time, it’s *easier to go to work in another company.

The other factor that can lead to the Usual Path is giving little importance (or sometimes demonising) to proper training. I personally listened to some C-level states that their companies cannot afford to train developers**. However, seeing the training as a mere cost is usually catastrophic for a software company.

In Flowing, we deeply understand the need for training that a software company needs to survive in the ever-changing tech world. Our solution is to give a yearly budget to every surfer (we use this name to indicate who works with us) to spend on training (conferences, workshops, books, etc etc.) and give proper slack time to study and test new ideas.

Moreover, every month we organize a Flowing Academy workshop. When a surfer is confident enough about a new technology or methodology, they book a monthly slot and invite other interested surfers to a Zoom meeting. The meeting itself is recorded and shared on our Slack workspace.

And yes, we joke a lot during these sessions.

This totally bottom-up approach has allowed new ideas to emerge and become part of our daily lives.

If your company doesn’t give you enough time for training, you may consider working with us! 😉

As a more general approach, when I notice some decision-making anti-patterns in a developers team. I usually dig deeper: the anti-pattern is always a symptom, never the real disease. Company culture is an essential part of any decision-making process.

If you have a bad company culture, you will probably make bad decisions.

Contact Me

I am gathering my experience in helping software development teams make decisions in complex environments in a book that you can buy on Leanpub and published by Avanscoperta.

If you want to contact me and talk about decision-making, contact me on LinkedIn.