The Usual Path: a decision-making anti-pattern.
In the last few years, I started to love boring technologies. It’s most likely connected with my age and a lot of 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 that I have with teams that are affected with 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 directive 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 helping 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 of Visual FoxPro, and with the years they become better and better. But they fall victim of the Golden Hammer law:
If all you have is a hammer, everything looks like a nail
When Microsoft announced that Visual FoxPro will 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 laptop 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 that it was entirely a technical problem, people were too lazy to study new stuff and they fell behind. But now I know that this is just the tip of the Iceberg. So, every time that I feel that a team is walking the Usual Path, I start asking 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 the failure. If you constantly fear that your team will be blamed for missing a deadline, you will choose to remain in the comfort zone. Because it’s easier to defend yourself if you say:
“We tried our best to not 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 times 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 state that their company cannot afford to train developers. But 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 need to survive in the ever-changing tech world out there. Our solution is to give a yearly budget to every surfer (we use this name to indicate who work with us) to spend in 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 life.
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 kind of decision-making anti-pattern 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 in making 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, my DM on Twitter are open! If you liked this post, you can buy me a virtual coffee ️😊
