Hacker News Reader

Comment by ktRolster | Hacker News Reader

I'd rather have confusing software that does what I want, than simple software that doesn't do what I want.

I'd suggest the proper response to this is, "Make the common case easy, make the uncommon case possible."

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.

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.

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.

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 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.

I'd rather have simple software that does what I want.

Then either other people don't have the software what they want (because there are so many different needs when it comes to any domain) or the complexity is transferred to finding/evaluating the huge selection of software.

LOL that's called having your cake and eating it too, AKA impossible.

Exactly. Our tools should not add a layer of unnecessary complexity on top of already complex domains. If anything, they should take complexity away so we can focus on what is most relevant for the goals that we want to achieve.

A lot of configuration options come into existence not because they are actually useful, but because the team had a disagreement that they couldn't settle, or because writing code that just figured out the right thing to do would be too complex. Options should be a way of empowering the user, not simply offloading work to them.

It's very important to realise that our goals are not just related to the concrete problem at hand, but include things like "get out of the way and don't make me feel stupid".

But then a lot of options exist because the domain itself is complex and can't be captured in a one-size-fits-all solution.

The only way to make something both very simple and very useful for a domain is to cunningly cut out parts of the domain. The end result is a pretty, simple and opinionated tool that doesn't really solve anything for anyone, but sure looks good on screenshots.

This. Most "disagreements a team can't settle" are rooted in fundamentally different use cases of a complex domain.

The real takeaway here should be that engineers tend to make UX that feel good to them as engineers, and most of their clients will typically not be engineers.

> I'd rather have confusing software that does what I want, than simple software that doesn't do what I want.

Of course you would, or I would, or anyone who browses HackerNews would -- but it's not necessarily the best UX.

If this is a business software, once the sale is done, users are going to pick it up because they pretty much have to. But the sale can easily fail in the first place if the product does not have a feature that particular customer wants, and the competing offering does.

Sensible defaults.

I remember learning a saying years ago on slashdot. Difference between Windows and Linux: easy things are difficult in Linux, difficult things are possible. Easy things are trivial in Windows, complicated things are impossible.

This was in XP era. Today the likes of Ubuntu/Gnome try their best to dumb down Linux.

Reply on news.ycombinator.com