[astine]

On the 'do one thing and do it well' issue, there seem to be two spectrums:

    1. suitability of a tool to multiple tasks
    2. number of features a tool has

This makes for sort of a field with four quadrants:

    1. simple but flexible tools
    2. complex and featureful tools
    3. specialized but simple tools,
    4. highly specialized and highly featureful tools

So take a tool like grep and it clearly belongs in the first quadrant. You can do a lot with it, but it's pretty simple to learn and use. Emacs (or Eclipse) belongs in the second quadrant as it can basically be used for anything and is complicated to learn. Something like MyPaint belongs in the third category and there are numerous domain specific tools that belong in the fourth.

So the question that remains when one is asking for a tool that 'does one thing well' is, do you mean for it to be specialized, or simple, or both?

[chipsy]

I came up with a three-tier model myself:

   1. API or API-like things (grep)
   2. Highly configurable app (Photoshop, Word)
   3. Default-heavy app (Instagram)

The tricky thing is that 1 and 3 are the easy slices, relatively speaking. If you only need the 80% case, it can probably be automated into something as simple as a selfie app, with a finite, well-understood level of design and engineering. And if you need something extremely custom, you want the data model exploded into its smallest parts so that you can put it back together again - and the small parts can again be relatively simple, well documented, and easy to maintain.

But the middle part, the product that is complex and configurable, but not really "programmed" with code except through a limited script layer, is the fat middle, because it demands so much more UI, and an experience that is well-integrated, amenable to default workflows, and yet also very easy to customize. Over time, big software projects always drift towards the middle.

The article specifically fits my model's type 1. A type 1 product is nearly ideal for the hacker who wants to glue together a bunch of different technologies. It only falls down when the abstractions are too crude or mismatched to the problem. But the operating system itself is more like a type 2 product - there are numerous assumptions about what the environment, services, access methods, etc. look like, conventions that were established early on in computing and haven't yet been revised. Every programming language makes accommodations for working in that environment, and not your weird custom operating system.

[ZenoArrow]

In this context...

"specialized" = Do one thing

"flexible" = and do it well.

That said, the key ingredient of the Unix philosophy that is missing isn't specialised, flexible tools, it's composability of those tools. Imagine if you couldn't pipe grep output to another program, wouldn't it be a lot less useful? I'd say so.

There are ways we can get around this, but they would require a fair amount of development time. To give you one example, consider how the JACK audio server allows programs to share audio streams. Similar data streaming arrangements could be made for other types of data.

[ybx]

How does flexible mean do it well?

"Do it well" is so vague of a saying that it really could mean any of those things, whether it be flexibility, or simplicity, or etc.

[astine]

My understanding of the phrase 'do it well' isn't as an injunction but as a way of saying that if you restrict your program to one thing, you'll have the ability to do it very well. It's to contrast it to a program that does multiple things, not so well.

[adjwilli]

What I understand flexible to mean is "serving 99% of use case scenarios". Arguably Photoshop does this, Instagram does not. Or maybe a better analogy is Photoshop vs Photoshop Elements, which probably only servers 80% of use case scenarios. Or Chrome OS (80% of desktop use case scenarios) vs Windows (99.9%).

[ZenoArrow]

As I said, in this context, it means flexibility, but that flexibility must be tempered with composibility.

Think about how programs become bloated. What helps the core Unix command line tools avoid this fate?

[hawkice]

There are quite a few things in the fourth category, and I'd like to say, for instance: Beeminder. Specialized, but there is a lot going on. Honestly, I like it. I could just keep a text file if I didn't want those features, and I honestly can't think of any features I would subtract. Which raises the larger question: are the advocating flexible but simple tools, straightforward but domain specific tools, or are they just advocating against building something that is a complete mess and a waste of time?

It's important to remember that while quite involved and extremely domain specific, Beeminder has an API. He seems to care a lot about that, and I have no idea if his real point is "make things that don't suck and avoid digital vertical integration".

[icebraining]

I could just keep a text file if I didn't want those features, and I honestly can't think of any features I would subtract.

But the point about simple & flexible tools is not to miss on features for the user, but to separate those into different tools. The people who prefer a simple text editor to an IDE aren't doing everything else by hand, but using a set of different tools to accomplish the same as the IDE built-in features would.

Taking the Beeminder example, and with the caveat that I've never used it: the graphing system seems cool, but it can't be used by anyone who doesn't have access to a credit card; if the graphs and the commitment payment systems were two separate tools that you could connect instead of a bundle, one could use the former with an alternative commitment system.

[dreeves]

I'm tempted to quibble that you can use Beeminder without a credit as long as you never go off track. But ultimately I think you're right, we're guilty of this. Ideally the Quantified Self part and the commitment contract part would be independent but interoperable tools.

[turs0und]

This feels like an over-simplification. Life doesn't fit into 4 quadrants, and the only thing models are guaranteed to do is be inaccurate. "One thing" and "well" are fundamentally subjective and based on a particular use-case. You have to focus on the problem(s) you're solving, and be disciplined about the scope of the problem(s) you're solving.

[Qwertious]

>the only thing models are guaranteed to do is be inaccurate.

My model of gmail is gmail. This model is 100% accurate.

[turs0und]

I don't mean this negatively, but I don't understand what point you're making...