Choosing New Dev Tools

Speed and quality of development is a differentiator for a company, but a specific tech stack is not. Which is why in my experience the simple, tried and tested tech stack is usually the better one to go for.

If you’re Digitalocean or Confluent then you’re going to be innovating a lot on your tooling and infrastructure. These companies often need to invent new tools in order to handle their throughput/latency/data size requirements. For the rest of us it’s usually not worth the opportunity cost.

So be clear about why you’re investigating a new tool to use. Are you driven by new and shiny? Or maybe it will be useful to train the team on something new out of interest (i.e. Resumè driven development). But most of the time it really should be about what is going to help the team deliver the best.

Don’t be lead astray by people who claim using a certain tool is right because it’s popular, new or backed by a large company. Take in the context of the team you’re operating in, what experience do they have in this tool for example?

Of course it helps to think ahead a little bit, will this tool scale once we get bigger? But too often I see this is over-emphasised and the team takes on too much complexity up front in the hopes it will solve scaling challenges later on. Sometimes the team will move so slow that the project is canned before ever reaching the anticipated level of scale.

Think from first principles, what will allow the team to build fast and with quality for the short and long term?