A decent tool for the job
Some thoughts on how to pick a technical platform for a software project — why we sometimes overestimate the importance of the decision, and what to keep in mind when you decide.
This article was originally published on March 17 2017 on the SthlmConnection company blog.
If you’ve been in the software development game for a while, whether you’re doing web development, apps or something else, you’re probably expected to know what tools are the best ones for a particular job. People rely on you for making informed recommendations about frameworks, platforms etc. The more experienced you become, the more decisive your answer will be. Right? Or is it the other way around?
I find that in some ways I become less and less certain about these decisions the more experience I get. At the same time, I worry less about it than I used to. In the past things were more black and white (X is good, Y is bad, and I’m not even aware of Z yet) whereas now I don’t care that much what you choose, as long as it fulfills the needs, and as long as you enjoy working with it. It’s what you do with the technology that really matters, which sounds very obvious when you say it.
It is an important decision, but what I’m saying is that it’s OK to relax a little bit!
Two things that I have learned: 1. For any individual problem, there are a number of technical solutions that will work equally well, more or less. 2. It’s really hard to foresee all of the implications of choosing a particular technology. These two combined tells me that a) it’s impossible to know which is the best possible tool for the job, and b) you’ll be just fine with any tool that is roughly appropriate for what you need to do. In other words, it doesn’t matter as much as you might think. Don’t get me wrong, it is an important decision. What I’m saying is that it’s OK to relax a little bit!
In an effort to be a little more helpful than that, the following is a checklist of sorts. Let’s call it How To Pick A Tech Stack That Is Mostly Decent And Not Harmful.
How critical is the decision?
First of all, think about how important it is that you make the best possible choice. What are the potential costs of making the “wrong” one? How hard is it to switch? If the product is small, short-lived or rapidly changing, don’t dwell on it too long. If you’re building a lunar lander on the other hand (you are, aren’t you?), it’s obviously a different story. Or, more likely, you have to choose a database for a long-term project. This is an example of a technology that can be challenging to switch later on. Another thing that I think deserves a bit more thought than other technical decisions is how to design an API, especially if it’s a public one.
When should you decide?
In general, it’s good if you don’t have to make the choice too early. At least, don’t decide on the technology stack up front — it may affect every future decision in the project. Instead, start by getting a proper understanding of the project. Especially if you’re a person with a tendency to act first and ask questions later.
Maybe you’re the opposite — you like to dwell on decisions and weigh all the pros and cons in all eternity. While it is good to make an informed decision, don’t let it become a blocker for your project. Just pick something appropriate and start prototyping. Switch early if it turns out there is a better option.
Flexibility
It is also important to recognize that it’s impossible to plan your entire project up front. The smart, shiny solution you have in your head right now is most likely not what the final outcome will look like. With this in mind, you should try to use solutions and tools that are flexible and easy to adapt to new circumstances. Avoid big monolithic solutions that try to solve everything. The worst situation to be in is when you’re unable to follow a new direction because you picked platform X somewhere in the beginning of the project. (Or, which is probably more common, because you designed your application in a way that makes changes hard to do.)
The tried and trusted vs. the new and shiny
Everyone has their favorite tools and platforms, or at least they have tools that they are more comfortable with than others. That’s fine, but try to avoid using your pet tool for everything — nothing’s that versatile. There is a whole world out there, and it has specialized solutions for virtually any problem you can think of. And every day new technologies crop up that are better than the old ones (well, at least in many cases they are).
You should probably pick something that your team is already comfortable with.
That doesn’t mean that you should always be on the cutting edge. The beginning of a new project — when you want to be able to move quickly and test out different ideas — is not always the best time to try out new technologies. Unless you are able to pick a team based on your technical flavor of the day, you should probably pick something that your team mates are already comfortable with. Having a great team is more important than being able to pick any technology stack you might like to use. Plus, as stated above, your second or third choice of technology will probably work very well too.
Technical merits
With those fundamentals settled, you should start looking at the actual features that you’re looking for in the technical platform. This will depend completely on the specific project requirements.
Is it suitable for the project you’re building? Is it performant, stable and secure to a sufficient degree? Is it testable?
Productivity
Will you be rapidly iterating on new features, or is stability or performance most important? If time to market is crucial, choose a technology that is fast to develop with, facilitates team collaboration, and adapts well to changes.
There is also something to be said for having a nice developer experience in general. A happy team is a productive one!
Besides the technology stack itself — consider what the tooling looks like for the developers that are using it. Is it possible for individual developers to use different tools, or are you all locked in a specific development environment?
There is something to be said for having a nice developer experience in general.
Sustainability
This is obviously mostly important if you’re starting a long-running project. If so, you should take a look at the organization behind the technology. Is is sustainable? Is it mature?
Is the technology stack open and “hackable”? You don’t want to get locked into a technology that doesn’t allow you to make the changes you require. Also, is there decent interoperability and compatibility with other technologies?
Learning curve
Even if you have a team that already knows the technology inside out, it is always beneficial if it is easy to learn for new developers. Teams change, and they are sometimes swapped out for different reasons.
Things that affect the learning curve are the size, complexity, and focus of the platform, and of course the quality of the documentation.
Cost
The development process itself is probably the most costly part of most technical projects, but you should also be aware of the continuous costs and any up-front fees that may be involved with using the technology — things like licenses and subscriptions. How do these costs scale when the project grows and becomes popular?
Hosting and maintenance
What types of services or equipment is required for running the project on the platform? What is the process like for deploying the project to different environments — development, testing and production? What is the process like for upgrading the platform to newer versions, and to apply security fixes?
The gut feeling
In the end, the people who will be developing on the platform should be the ones to decide. What makes them feel the most productive? What makes them happy? What does their gut feeling tell them?
Originally published at www.sthlmconnection.com.
Image credit Janko Ferlič
