Tools. So important.
Imagine someone picks up woodworking and asks himself: What tool should I get? A hammer? A saw? Screwdriver maybe? The first answer is, probably, that it depends. The second answer is that you’ll likely need all of them on your journey. And someone else will probably throw in that if the only you have is a hammer, every problem looks like a nail. Nailed it.
Tools are a big topic when building software. And they need to be. They’re what enables us to build and run software in the first place. Whether that’s code editors, libraries, frameworks, plugins, databases, runtime environments – you name it. It’d be completely impossible to start from 0, so we’re using things all day, every day. Not all of it is important, of course. Whether you locally use a Mac or a Windows machine shouldn’t matter that much for anyone but you. The tools, the blocks, that make up the thing you’re building are far more relevant.
As a blast from the past, when web hosting became wildly available something like 20 years ago, you’d very often get conveniently priced combo packages that included some space on a web server that could execute PHP and a MySQL Database. That was your tool selection, right there. That’s also why a lot of folks where PHP (or before that, Perl) experts and could deal with MySQL reasonably well. It’s also why WordPress is as popular as it is.
Before reading any further, remember I’m talking about tools. Hammers, Saws, Databases. Just things to help you get a job done. I’ll also acknowledge that there are tools that, in itself, are just bad tools, but it’s not something I want to explore today.
What I want to explore is something that I’m just going to call tool fit. If you have a nail, a hammer is a perfect tool fit. For a screw, a hammer might be a tool fit – but it’s not a given. Only in some situations. If you’re building a blog, PHP and MySQL might be a good tool fit, while they’re a shitty idea to use for a in-car entertainment system (haven’t tried, might work just fine). Poor tool fit.
We’re, as an industry, quite obsessed with finding the right tools. Good tools. Tools that make our life easier. A while ago, that was NoSQL Databases. Then it was stream processing, then it was Postgres, then AWS, then virtualisation, then containers and so on. And we’re invested, as individuals, into tools, by being familiar with them, by having experience using them. But the effectiveness of a tool depends primarily on whether it’s a good fit for the problem you’re trying to solve. There are no good tools per se, only good tools for a specific job.
What I’ve witnessed a few times was an interesting transition, one that you might have seen as well. A tool is used in a high tool fit context. Think web application and a relational database. Now a new problem comes along, one that will seriously stretch, or even exceed the range of problems that a tool can be used for in a sensible way – and something remarkable happens. Instead of taking a step back, carefully evaluating whether other tools might effectively provide a higher tool fit, the existing thing is used. Because it exists, because people have experience with it, because it’s hard to learn something new. And a technology that could be used to solve one problem has now to be fought in order to solve another.
It’s hard to spot when exactly this happens – when something useful, something that helps you to get something done, turns into a something that you invest a lot of time into. When the problem you’re having becomes hard to explain, the answers on StackOverflow become fewer and the docs are intentionally vague. That’s probably a good time to take a step back and reflect.
No one ever got extra points for sticking to the wrong tool.