Technology Misuse

It’s amazing how much you can accomplish with the wrong tools. Even more amazing is just how much tech debt this can give you.

It starts off innocent enough: you want to do something new and you’re not sure which tool or platform to use. Eventually you find one that seems to work, and off you go building your project. The problem is, it’s really easy to choose the wrong tools when you’re first starting out – and now you’re creating a webapp in bash, or archiving files with JSON instead of tar, or using SVN for metaprogramming, etc.

Unfortunately most of us learn this the hard way: just because you can make it work, doesn’t mean it’s a good idea.

Driving Factors

There can be a few driving factors behind technology misuse:

• Ignorance: When you don’t know that a better tool exists.
• Underscoping: When you only care about getting the MVP out the door, what happens afterward is someone else’s problem.
• Low Standards: The product technically meets all the requirements, so what’s the problem?
• Rigid Development: The wrong tool was selected during the design phase, and you don’t have the power to change course.
• Not Invented Here: Technology omission can be just as bad as misuse.

Identifying Misuse

A telltale sign for systemic technology misuse is that you never make big changes to pretty much anything. Even if you maintain your codebase with small changes, you never re-architect anything, never migrate from one platform to another, etc. In this case, you’re locking yourselves into whatever solution you stumbled upon first, which inevitably includes some early architectural mistakes and small-scale solutions you’ve long outgrown.

Ironically, another telltale sign is if you migrate and re-architect all the time. This can be from insufficient research: you want to use the right technology, but you can’t find it.

For individual products or systems, there are a few ways to spot technology misuse:

• You’re not using most of the features, or you even find you’re fighting against them.
• You’re building something in-house but you suspect it’s a solved problem.
• The vendor’s usage tiers don’t line up with the size of your organization. (Too small or too large.)
• There doesn’t seem to be any advantage of using the technology.

Worse Than Nothing

Particularly ill-fitting solutions can be counterproductive. Consider an “automated” system which is more time-consuming than doing the task manually, or a task-management system that makes you want to throw your hands up and go back to pencil-and-paper.

As such, when choosing or developing a solution, it’s always pertinent to ask: Is this better than what we already do? If the answer is no, don’t move forward just to check the box, keep looking for something that will actually make things better.

In a Nutshell

Don’t buy a cannon when you only need to hunt squirrels. Don’t use bash to handle complex data structures. And for goodness sake stop calling external commands in a shell only to cancel the shell’s features by escaping everything (seriously, everyone does that). All of these will work, which is what makes them so dangerous.

Whenever you’re building something new, don’t just ask “Will this work?” Also ask “Were these tools meant to do this?”