Software should do one thing well

Avoid the Land of Feature Creep where the Tech Debt Lies

source: Smithsonian

Most people know a Swiss Army Knife on sight.¹ It's a tool that exists not to be a single tool, but as a compact collection of multiple sub-tools.

Each sub-tool is fundamentally a sub-optimal experience. A knife that is just a knife would be better than any knife on a Swiss Army Knife. A screwdriver that is just a screwdriver would be better than any screwdriver on a Swiss Army Knife.

The purpose of each sub-tool is not to be the best experience of that tool. Its main feature is being available at all, and it achieves this by stuffing many tools in a small area. A bad knife is better than no knife; a bad screwdriver, better than none.

A Swiss Army Knife is a good tool, because it fulfills the design constraints of physical reality. When the option is between a lot of bad tools that can fit in a pocket or missing out on one of them, you choose lots of bad tools.

One Tool to Rule Them All

We don’t need any software to be a Swiss Army Knife, a bunch of bad tools stuffed together into the same tool. We do not have a space constraint with software tools.²

In software, if you put lots of tools together, you make it confusing and hard to use with other tools. You don’t have one good tool. You have a bad one.

This is not news. It's been known since at least the 1960s when UNIX was being made, and it was one of the primary conclusions of the failed Multics misadventure.

But having the knowledge out there is not the same thing as learning the lesson, and it has not stopped people from trying to shove everything together into one tool. In fact, it seems to be the default motion.

In order to make my point, I'm going to pick on a couple well-known tools. You can argue potentially that any one of these features is fine, but as a set, it begins to become a bit much.

Jira

Jira is a task or project management system, depending on who you ask.³ Some of its features⁴ include:

• a low-code feature set for various automations

• status workflow variations per project per task type

• field layout configuration per project

• a large variety of canned reports and dashboard gadgets

Slack

A tool originally meant for text conversations with co-workers or other people in some kind of organization now has as part of its feature set:

• file sharing

• audio/video recording

• video conferencing / discord-style voice chatroom

• workflow builders for automation

• a wiki/notion-style note taking

One Tool to Bring Them All

A big reason that many companies go the path of more is to get that next big customer or the next 10x user growth or to increase TAM for investors. The belief is there’s a logical domino effect: more features, more users, more LTV, and more value to shareholders.

Many times these ask for more comes at the request of users themselves. The motivations are wide ranging:

• I use 3 apps for this. Why not just yours?

• I’m clicking too much to get what I want done. Why not build a feature to automate that?

• This menu item is too buried. Can you pull it forward?

Too often the people in charge hear that request and say, “Oh yeah, we can do X.” And they stack it on top of all the other features to make, and eventually it’s another one to maintain.

You need to have a clear statement of what you’re doing because your users won’t. They will always be focused on a their own use case. How could they not be? It's your job to ensure that your system continues to do one thing well for all of your users’ use cases.

And in the Wall Garden Bind Them

The main problem with the One Tool is that at some level the company making it achieves its goals. It's just that the goal of the companies making the One Tool progressively do not have the same goal as their users.

Users want tools to do their jobs well. But companies have a strong incentive for profit. Eventually, the idea becomes that they can provide everything for their customers, and they pursue a strategy that sounds like multiple tools each doing their own thing. But they’re part of a suite that only really works together inside their Walled Garden.

Once an organization makes this pivot, you’ll notice their APIs aren’t as good as they used to be, or maybe they’re completely missing any new functionality in their APIs.

It’s at this point you are given the choice: should you leave your vendor’s warm embrace, or should you go all in?

The One Tool Already Exists

Universal solutions already exist and have for a long time. You don't need to make them, but you can if you want. They're called programming languages.

Do not misread what I said, though, I did not say that programming languages were the One Tool. I said they're the universal solution.

The One Tool is the person making the tools.

It's like the old firefighter prank on new firefighter: "Go get me a hose stretcher." The new firefighter is the hose stretcher.

If your job is to make software, you are the hose stretcher.

Part of your job is to reduce the degrees of freedom down to be useful to another person, to think through the problem space, and to make it easy to use.

If a software engineer you already benefit from this, you don't have to understand how:

• ps gets data about running processes

• grep searches files and returns the results to me

• Postgres or MySQL stores rows on disk or retrieves them

Are you prohibited from learning these things? No, not all.

The point is that each of these tool is narrow enough that you understand what it does. It doesn't do everything.

As soon as any tool starts to do too much, the abstraction leaks and you need to understand too much about the internals of how it does it at some level.

Each Do One Thing Well

As I said at the start, this is already known back in 1978 from the UNIX Time-Sharing System Foreword in Bell System Technical Journal. Here are selections from that:

Make each program do one thing well.

Expect the output of every program to become the input to another, as yet unknown, program.

The fact that these 2 imperatives were stated in 1978 does not make them out dated. We have just lost our way recently, and I hopeful we’re turning a corner.

1. People might have been conditioned to call them multi-tools instead by multiple lawsuits trying to enforce trademarks.

2. Someone will point out how large software can be, but I'll just raise an eyebrow at them and ask for them to say what they said again very slowly so they can understand the import of claiming stuffing a bunch of things into the same program can save space.

3. Jira is the worst project management system in existence, but it’s better than all the others. In my opinion Jira doesn't really help you manage projects since it was originally meant to be a bug tracker and everything about Scrum or Kanban was slapped onto it after the fact. It’s readily apparent to any one who makes a new project and wonders how you’re supposed to do any amount of planning in relationship to time. It just hurts.

4. Jira also has so many features and so many plugins and even more integrations, that somewhere in all those things, there exists a system that works for you. You can indeed customize Jira to your heart’s content. I’d argue that maybe you shouldn’t, but you can.