Hacker News Reader

Comment by adrianN | Hacker News Reader

I'd rather have five simple tools that do what I want than one tool that can in principle do what the five tools do if you massage its configuration enough.

View on HN

Would you rather massage the configurations of 5 tools? Or figure out how to transfer data from one tool to another (because I bet you that in most situations there's going to be slight - and annoying - incompatibilities) between what each tool expects.

At any rate, it's useless to talk about this in absolutes. There are times when your option is better () and when it's not.

I'd imagine it's when you're in full control of the input and output format for each tool, each tool can be configured to work with varying formats, when there are times you want to skip steps in the processing pipeline...

I agree it's useless to talk about this in absolutes.

But personally, I find composing separate tools helps me learn and debug because things are compartmentalized.

I was messing with a tool (where the equivalent tool at other places I've worked was 5 or 6 separate command line tools) where the command line help is 1,441 lines long. I dread having to look through it and still don't really understand most how to use it.

In other words, Unix (modular agile) way vs Windows (bloated monolithic) way.

The problem is that Windows way seems prevalent (or maybe I'm overestimating it). Perhaps, much to my joy, a focus would shift soon, but that doesn't look like it will given the abundance of new installs for the win10 nagware.

The way this plays out, it sort of reminds me of Linux (you can do whatever you want, but you're on your own!) versus Apple (we know what you want even better than you do). As a developer, I'm loathe to see my precious configuration disappear, but I can see the appeal for minimalist interfaces from the user perspective.

My experience tells me that the price you pay for being able to do everything is having to figure out how to do anything.

That's a reasonable trade-off, if the sole alternative is being unable to do something that you need to.

In my real-world tool kit for household use, I've got a configurable screwdriver with multiple heads of various sizes and shapes (slot, cross-point, etc.). I also have a bunch of conventional screwdrivers. I use the latter far more.

But when you come across a Torx screw, I bet you're really happy you have the configurable screwdriver.

Actually I have a Torx screwdriver too -- and the multi-head configurable screwdriver doesn't.

Opposite anecdote: I have a bunch of conventional screwdrivers in a toolkit, too, but I also have a single configurable screwdriver in the kitchen in a drawer. Rather than going out to the garage to dig through the toolbox, I find that most of the time I just use the configurable screwdriver. It's not as good at actually driving screws, but it's faster to change the head and do whatever needs to be done.

I often feel the same way too, but not because of difficulty of configuration -- in fact, in this case, you would have to figure out how to configure each of the five tools, so if anything things become trickier on that front.

Why? And what if that one tool came with five common configurations for the five usages?

Because simple tools are easy to understand and easy to replace when you find something better. Once you invested a lot of time into configuring your GenericTool(tm) to do what you want you're locked into its ecosystem forever. Also, simple tools that do one thing only tend to do it better than tools that do lots of things.

What if that one tool came with five configurations for your five usages, that you wouldn't have to touch?

You can still replace one usage with another tool, if you like. I think that the idea of many simple tools is good in theory, but seeing that most important codebases last for ten or twenty years, use of many tools increases the likelihood that you've introduced a dependency on a product that may be discontinued/unmaintained. "Easy to replace" is fine if you're very familiar with the code and all the assumptions it makes about the product's behavior, but if a tool that some module of your system that no one has touched in more than five years all of a sudden disappears[1], replacing it may be almost as big an undertaking with replacing the one big tool, but the chances of that happening are greater (because you have more such tools, and small tools are more likely to be discontinued than big ones).

[1]: Say, by no longer supporting your new hardware/OS.

Replacing just part of a big tool because there is a better alternative doesn't fly with management ("we already paid for big tool and it does what you want, why should we replace a part of it? It will just increase the complexity!"). I see small tools disappearing occasionally as a good thing. You should always be prepared to change parts of your system and a larger organization should have people that continuously work on improving the tooling. Assuming that your tooling will work indefinitely leads to ossified systems that can't be upgraded at all.

Imho, tools should be treated just like code. You wouldn't write one big function that takes half a dozen parameters to change its behavior. You refactor it into multiple functions that are easier to understand and improve when requirements change.

Reply on news.ycombinator.com