We started building web applications in the late 1990s, during a time where the concept of doing so was still very young. The target browsers were Internet Explorer 4 and Netscape Communicator, Javascript was only just being standardised (and was still fighting with JScript from Microsoft) and most webpages were still being built with tables, font tags and lots of marquee elements.
This lack of maturity in the medium made choosing the right tool for the job very simple - because there were so few tools to choose from. Most HTML was written by hand, probably more websites than you can imagine were simply code in Notepad, and WS_FTP was all you needed to take that and send it to your server. When we started working with Perl to create more dynamic websites and started introducing database driven options, MySQL was only a couple of years old and never seemed like a tough choice. These were just the tools to get the job done. Like taking a fork and knife from the cutlery drawer.
As the years have passed, the number of people building websites has obviously increased massively, as has the number of people online. This has resulted in a parallel increase in the number of people who think they can create better tools for those websites to be built with. Unlike the physical world, tool standardisation simply hasn’t happened yet. We’re still at the stage of trying to hang pictures with a rock, and haven’t settled on the claw hammer yet.
Tool generation can also be a very lucrative business. For every consumer facing success - Instagram, Spotify, TikTok - the thousands of people involved in creating these products need a set of tools they can rely on. From the programming language itself and how they manage that source code, to how they build it, test it and deploy it, even project manage it. All of these areas, including all the non-development areas too (email hosting, managing staff holiday requests, CRM) have countless companies creating their version of the spoon that they hope these companies will pick from the drawer.
While this explosion of options would seem like a great thing for everyone involved, it creates what we’ve always considered to be the fallacy of choice. The excessive number of tools available makes companies scared to pick any of them, fearful that they’re going to regret it later. In some cases this may result in them not picking one at all, causing problems when they stick with whatever broken system they had already. In other cases, it creates problems within development teams where not everyone agrees with the choice that was made.
This problem isn’t going to get any better. Even we see the opportunity for launching our own tools into this very crowded drawer. So if you’re actually looking for a knife when all you can see is spoons, is there actually anything you can do?
To start with, you need to accept that there is unlikely to be a perfect answer to your problem. Everything has tradeoffs, and even though a spoon might not cut as well, it can probably scoop better than a knife can. You need to decide on what you absolutely can’t live without - and then be prepared to live without them when nothing fits.
Secondly, look at what others are doing. The wisdom of crowds can be very strong, even if you don’t necessarily understand why so many people use something Jira, there’s probably a good reason why. Sometimes it makes more sense to fall in line with what others do, rather than trying to carve your own path.
Finally, sometimes you just need to make a choice. Any choice. Only with the experience of using a tool or library can you properly focus on what it is you’re actually looking for. Don’t treat every decision as final. If it doesn’t work for you, replace it. Free yourself from the stress of getting it right first time.
And if you’re still looking for help, contact us and we’ll see what we can do.
Photo by SHATABDI ROY on Unsplash