Is tool fragmentation really a problem? People tell you to buy all-in-one solutions to combat it. But I think the symptoms don’t go away with these tools. You still see shadow IT/shadow DevOps. You still have multiple tools and context switches. You still have data impedance mismatches because you still have multiple blessed and latent tools.

Maybe the problem is just poorly specified goals, unclear modes of communcation, and a lack of leeway to experiment with different ways of doing things. People never seem to know what they are asking. Everyone seems to have different presentation and communications preferences. All-in-one tools seem so stifling and generally disliked. Do you know anyone that loves Atlassian or O365 or GitLab? Is anyone really psyched about the AWS Console?

I am biased towards the unix philosophy. Even the barest unix machines have a panoply of tools. The system as a whole relies on composition, simple/narrow-scope functions, text-based contracts to bridge abstractions, simple abstractions. These taught me the power of separation of concerns. Modularity lets you hot plug broken components without boiling the ocean. It gives you a bunch of building blocks for free. It lets you define contracts to mediate isolated functionalities that you can improve independently from each other. All-in-one tool aspirations seem weird to me.

People have been talking about “single panes of glass” and “single sources of truth” for well over a decade. No single tool will seems to be able to do it completely, partially because it’s hard and partially because the world keeps changing. Maybe that’s why you have teams spending 6-12 months to spin up a minimal internal platform portal, if they don’t give up altogether.

These are also, perhaps, deceptively complicated asks. “Single pane of glass” sounds nice until you realize that many people do not operate well this way or even look at things in the same way. They do not spend time staring at web dashboards, they respond to events or investigate via the CLI, do chatops or make DB queries.

“Single source of truth” also sounds nice until you realize that “truth” for any named system has many referents. Human parameters? Computed parameters? The code? The declared intent? The checkout state? The cluster state? Is it partitioned? Or do you mean the health check of the resulting running app at this moment? Which instance? What about the actual app behavior agains baseline? For which authenticated users? From which region? There is no single set of objective truths about a system, it depends entirely on what and how you are asking. All of the previous example qualifiers are relevant in the real world and very few of them are succinctly surfaced in any “single pane” in the wild.

We will probably be living with “tool fragmentation” forever because that is how the tool use seems to work. People reach for or invent a tool that gives them the best chance to solve the specific problem in front of them, and that inexorably leads to a collection of tools that evolves over time. Look at a mechanic’s toolbox. Look at the task bar on an developer’s Mac, look at any manufacturing floor. Only in the most utopian science fiction do you see “matter programmer” tool that transmogrifies anything or a “tricorder” that senses everything. In a real toolbox, that all-in-one tool spends most of its time idle in the back of the drawer because it is seldom the best tool for any job. I supsect unix was designed by people who intuitively or explicitly saw this as an unavoidable fact of working life.

None of this is meant to say that multi-function are inherently wrong or bad. Hammers with nail pullers are ubiquitous without any obvious drawbacks. But if trying to shrink a large toolset, it might be more realistic to consider “one tool for everything” a directional mood rather than a literal goal. Maybe instead of fighting everyone’s varying approaches with approval processes, decision matrices, device management and developer portals, we should instead try to to harness and learn from all of that distributed effort by people experimenting with and building tools for the problems they are facing.