Choosing the right technology for the right project
Every time that I start a new project with a client, the first problem to solve it’s to choose the right technology for the project. Let’s take a mobile application for example. We can use native SDK in Android and iOS to build two different applications, with different codebases. Another option is to use one of the many JavaScript frameworks out there like React Native or Ionic.
Obviously, there are other options but this post is not about “why” choose a technology, it’s more about “how” to choose it.
At first glance, the native approach is the “best” one. You don’t have the limitations of a framework that works above the native SDKs, so you gain in freedom and performances.
But the “best” technology, it’s also the best way to satisfy your client?
Often developers choose to write native applications without worrying about the real business need of the client. A native app built in the wrong context it’s like a Ferrari in the desert, probably your client just needs a camel! :)
So what’s the best way to choose a technology? In my opinion, the first thing you should do it’s to understand the business needs of your client.
Take a startup, for example, its primary objective it’s to hit the market as fast as it can. So, the best choice could be an Ionic application: one codebase with an easy-to-learn framework in order to keep your velocity high enough.
In other words to choose a technology you need to know “why” your client needs the project, and not only“what” that project has to do.
In our company, before starting a new project we always do a “discovery” meeting with our team and the client. The purpose of this meeting it’s not only to understand what the software will do, but also what is the business needs that our client wants to satisfy with the project itself.
For this reason In the initial phase of the meeting, the client does a sort of “elevator pitch” when the client explains the business model behind the idea. In some cases, we also build the Business Model Canvas of the project.
Clearly, we also need to understand “what” are the features that we have to implement. But we also need to comprehend the context where this project actually “lives”. In order to achieve this goal we often continue our meeting with an EventStorming workshop. With this format, we are able to describe what the software will do, but also to find out what external systems or organizations will interact with it
“What” a project does isn’t just a bunch of user stories, but it’s to understand all the relations between the software and the people (not only the users) involved.
Now, we know “what” to do and we know “why” we’re doing it. But what about “how” to do it? There’s a lot of exercises that we do during our discovery that let us understand that. One of the exercises that helps me the most it’s this: we simply ask our client to order these four factors by importance.
It may seem a useless question, but working on a project where the order is quality/scope/budget/deadline it’s quite different than working in a project where the order is deadline/budget/scope/quality.
Let’s go back to our mobile app, if you find yourself in the first case, probably it’s ok to use native SDKs. Because of the fact that the quality it’s so important probably means that your app will be a cornerstone in the business model of the client.
In the other case, probably the app it’s just a piece of a more complex value proposition for your client. So it’s ok to use a framework that helps you keep the velocity high enough in order to don’t miss the deadline.
Our discovery meeting helps me to fully understand what it the purpose of the project, what it should actually do, and also how to do it. In this way, I’m confident about choosing the best technology for the job.
So, in nutshell, how to choose the right technology for the right job? Simple. Just ask the right questions to your client.
And remember that choosing a technology, like the most of the problems in software development, it’s all about people!
