As a programmer I’ve been taught that picking the right tool for the job is THE THING. I’m thinking here about the kind of decisions that are based on combination of extensive knowledge (not only tools, but also paradigms behind them and their limitations) and lots of thinking (most likely inspired by solving challenging, real-world problems).

But looking at projects I participated in I realized that picking the tool is only one tiny step in a very long journey.

Here are a few challenges that I observed as far.

The right tool won’t help you if you use it in a wrong way

I have very little experience with NoSQL databases as far, but a few things surprised me already. In SQL we usually start modelling by thinking what data we have and what would be the best way to store it. But in NoSQL databases we need to start by thinking how we want to access this data and optimize structure for that goal. What is considered a dubious practice in SQL world might be perfectly acceptable in NoSQL one (e.g. data duplication is very common).

If we don’t know how we’re going to use the data then I don’t think it’s possible to come up with a good model. You can’t just make it up as you go, because you’ll end up trying to build SQL-like model for querying on top of NoSQL database. That means you’ll have great performance problems. For example, document databases work best if you access documents by ids and if each document is an independent aggregate (meaning it contains all the data you need at the moment). If you create lots of tiny documents and top it up with many indexes, with each index touching the majority of the documents to check a single field on them… Well, probably it won’t work well in the long run.

I’ve came across similar situation a few times. Usually the problem was that the person who picked the tool understood it really well, but wasn’t involved in implementation or was involved in a limited capacity. Think typical architects, typical “enterprisy” software development process, or just not enough code reviews.

Image from http://www.omniref.com/blog/blog/page/2/

The right tool won’t help you if your problem changes

… and you don’t notice that the once perfect tool doesn’t fit the problem any more. Or worse, you notice but can’t switch the tool because of other factors (like cost or time limits).

That change might be the result of new requirements, growing understanding of the system, or using the system in a new context, e.g. when you find access to a new type of clients.

That situation can lead to the previous point. It’s hard to decide when the line is crossed and it’s time time to stop abusing our perfect tool to fit the new problem. It’s even harder to do it when we have limited resources and are expected to keep delivering.

The right tool won’t help you if you solve a problem you don’t have

I’ve seen two types of situations when people solved problems they didn’t have. One is the infamous premature optimization. It’s very hard to resist the temptation to use your skills to the maximum and just aim for the simplest thing that works. It’s also very hard to accept that you can’t predict the future requirements, and what seems like a great idea today might turn out to be a waste of time tomorrow.

The other situation is equally popular communication issues resulting in misunderstanding what the actual problem is.

Image from https://medium.com/interactive-mind/the-evolution-of-ux-f27dd1ac56b4

The right tool won’t help you if you solve a problem that is not worth solving

The great example would be adding lots of features to the system, knowing well that only a very tiny percentage of users will use them (or maybe none at all). It’s estimated that 30% of features in our systems are not used or rarely used, so don’t think your system is an exception.

Working on problems that are not worth solving not only generates maintenance costs in the future, but also is a lost opportunity. We could’ve be working on something else instead.