Oftentimes, a new project starts and there’s debate about which programming language and technologies to use. Of course everybody has their favorites and picking the favorite language to do the job is a fair choice if everybody can agree to it.
Though sometimes it’s not that easy. I once came into a new project where before I got asked “Oh Jan, do you know Python?” — “Uhm, yes. It’s been a while but I can manage” I answered. In that project the task was to help the client building a new software as a service product. At the time the tool of choice for me was Ruby on Rails, mostly because we usually would do Ruby projects, but also Rails was the best tool I knew to get that job done.
So, I was a bit confused first, asking my boss about more details. I learned that he already started to work on the project, therefore technology choices had already been made. Furthermore, I learned that at the client’s company there’s another person writing code who’s actually a mathematician. They’re working on a software producing the data which shall be viewable by the part I was supposed to work on. That other person was using Python for their parts, because it has the best integration and libraries for machine learning and complex mathematic models. So we had a compelling reason to also use Python, also making collaboration between our projects easier.
This has taught me an important lesson:
In order to pick the programming language and the libraries not just my preference plays a role but also how these choices fit into the bigger picture
What does this mean on a more abstract level?
When a new project starts and choices have to be made, take the following things into account:
- Is everybody comfortable using the programming language / libraries?
- If not, is it possible for people to learn these in reasonable time?
- Do you have know-how about deploying an application written with this language / technologies?
- Do you need to hire more people? Is it easy to find people who are knowledgeable in this programming language / technologies?
- How long does it take you and your team to be productive to deliver value to your customers?
The purpose of the checklist above is to encourage you to reflect your technology choices on multiple levels, like can everybody work with the tech stack right now? Are you able to find people with experience in your current tech stack? An example:
You’re using Rust + Rocket (a Rust web framework) to build your product. Now you’re deciding to hire more people. As of the time of writing this, you’ll probably find people who know Rust already but probably it’ll be difficult when it comes to experience with that particular web framework. On the other hand, if your search for Rust people is not successful, consider to view it from a different angle – Rust’s general language design is influenced by Ruby. Therefore if you widen your search for people with Ruby experience you might be more successful. Also, Ruby developers usually have experience in building web applications, where Rocket (but also other web frameworks / libraries) share a common design. As a result, if you find Ruby developers who are willing to learn Rust in order to to ship web applications you’ll be more successful in hiring the right people.
Another important factor when it comes to making technology choices is, you need the know-how to deploy and operate it. Have a look at this example:
Let’s say you’re using Ruby on Rails or Python together with Django to build your web applications. In order to deploy either of them you need to install Ruby / Python on the web server, prepare the application directories, place production config files and you’re done, more or less.
Now your new application is written using Elixir and Phoenix. Development progresses well, though when it comes to deploying your application it’s costing you more time now. Why is that? Elixir applications need to be compiled before they can be deployed, production configuration files need to be present at compile time already, your web server needs to have all the Erlang packages installed. For the first deployment you need to figure out all these steps, but also you need to train the new process around it. This takes time. Time you can’t spend on delivering value to your customers.
The point of this example is not to discourage you from making these kind of technology choices but to raise awareness for the costs they can introduce. If you’re on a tight schedule to deliver something, pick the technology everybody has the most experience with – for development but also for deploying and operating it. It might not be super exciting but you can hold your promises you made, at the end of the day it’s your customer who’s paying you.