5 ms·

So where does this leave complex, professional-level applications? Sure, a home user doesn't want that high-end coffee machine. But a professional Maker Of Cof

So where does this leave complex, professional-level applications? Sure, a home user doesn't want that high-end coffee machine. But a professional Maker Of Coffee does; that's a tiny cut-down example of what you'll find in pretty much any coffee shop you visit, being used to crank out at least a dozen different drinks multiple times a day. Or compare a kid's first toolbox to a fully-equipped carpenter's workshop full of power tools. Those power tools can rip through raw materials a lot faster than hand-powered ones, and can also rip through your flesh if you're not careful; they come with manuals, there are safety precautions you need to learn to use them. That said it is certainly nice to: - have all the configuration switches for your app in one place (a story: I've been using Adobe Illustrator regularly since 2000; it wasn't until like 2010 that I accidentally double-clicked on the pencil tool and found out that it has settings that don't live in the main 'preferences' window. Its defaults are IMHO terrible and made it a useless joke of a tool; once I'd found that it has settings it suddenly became the way I draw 90% of the shapes that make up my art.) - have sensible defaults (see above parenthetical story) - make your app easy to get running, which a hell of a lot of programmer tools certainly are not.

chipsy 11y ago
Complex applications are the worst of both worlds. They don't do things intuitively, they invent unconventional UI paradigms, and they are extensively configurable, so they need a manual that begins with "how to read this manual". The workshop analogy builds on a false premise of low configuration equating to underpowered function. A pro will use a lot of different speciality tools that have no or minimal configuration, vs. a Swiss Army Knife that is mediocre at everything. In the same way, Unix-style workflows are very "shoot yourself in the foot" stuff, but formal configuration of each tool is minimal. The best thing a complex application can do is be a general-purpose programming API at its core, with common workflows surfaced as a polished, simpified UI. Each of those workflows is its own application, with internal developer documentation to orient someone who wants to hack on it. Then the 80% cases are solved by default, and the 99% cases("this thing doesn't let me configure x") are solved by copy-pasting the application code and modifying a single line based on a Stack Overflow answer. And everything beyond that, you had to code anyway, so you enjoy a real programming environment with documentation instead, and hopefully a hook into the broader ecosystem so that the API is available throughout different coding environments. Sadly, almost no application intentionally evolves in this way.
- KayEss 11y ago
  AutoCAD always has. The GUI is really nice, in that it understands how to build the LISP commands that actually implement the system. You can put in a template LISP command and tell it where you want a 2d point, or a distance and the GUI collects these and fills in the values. It can even do embedded calls to generate these from other things. It's extremely flexible and allows you to arbitrarily build new commands that are easy to use. I automated a workflow for a drafting studio I worked at in 1989 and reduced the time taken to complete a drawing from three days to three hours just by writing new LISP commands for all of the most common things we did and wiring them up to the menu on the tablets we had.
Kalium 11y ago
> So where does this leave complex, professional-level applications? Nowhere. According to the rubric set out here, there are no such things. They aren't applications at all. They're something else, something different, and compilers should be just as simple as Fart Noise Maker 3000.
- jonathankoren 11y ago
  `gcc foo.c` gives me a working executable. That's pretty simple, and guess what? I didn't have to configure it at all! The idea that "professional-level applications" (whatever those are) should be shipped in a non-working state is absurd. The fact that Fart Noise Maker 3000 should should be shipped in a non-working state is equally absurd. Seriously, if I updated Babel and it suddenly was broken, I would have said, "Fuck this shit," and deleted it. There's just no point even trying to figure it out. The previous version worked, and life is too short to deal with this type of stuff.
  - Kalium 11y ago
    I use lots of professional-level applications that do simple things - like proxy connections to other applications - and require configuration before they work for my needs. That's because their nature means they cannot function otherwise. To expect that, say, a web server knows my need to serve a particular file from a particular directory a priori is absurd. But according to this rubric, I can and should expect things to Just Work. Does this mean I should expect pgbouncer to automagically discover what server it is to be pooling over, and that if it doesn't it's broken? It's silly. Real tools are often more complex than drool-proof iOS Apps. We do ourselves a grave disservice by pretending otherwise - or even by pretending that this is desirable.
bpchaps 11y ago
I think with professional level applications, the same thing can be said, but with a shift in gradient. Why wouldn't it be? I've been working with logstash a bit lately and... oh my god. The documentation is outdated, the initial examples have examples without explaining core principles, the log messages are almost useless, it takes about five seconds for the damn thing to even /check if the config is valid/ and holy mother of god if I see another line saying that something's been deprecated..... Also for the love of said god, when a bug report is filed and the dev needs to explain in multiple paragraphs why something undocumented is actually feature, not a bug... there's something truly awful. https://logstash.jira.com/browse/LOGSTASH-1348 https://logstash.jira.com/browse/LOGSTASH-1348 I can understand how these things happen, I truly do. But for something as widely used as logstash? No! Bad devs! The simple fact that folks on stack overflow recommend to use two different grok creation tools to get logstash working properly (unless deprecation, because hey why not) is a complete and utter failure in my eyes. Also, while I'm at it. I worked for an HFT firm that started going towards the devops stack, which required an install of Logstash. Installed it everywhere... I got woken up the next morning that every single machine was running cripplingly slow and that the trade desk had to cancel all orders. Huh. I installed it, but I never actually configured any of it to run... Welp. A ps showed that logstash-web was running..... but with a 5 second uptime? Turns out logstash-web's configs come installed with a bad config file that caused it to RESTART OVER AND OVER AND OVER. It killed any core the start job was running on for a good 10 seconds and immediately came up on the next. How...... why.... no..... :( Thanks, Logstash. I seriously hope somebody from your team reads this article. You're in absolute desperate need of usability lessons. /rant

chipsy 11y ago

Complex applications are the worst of both worlds. They don't do things intuitively, they invent unconventional UI paradigms, and they are extensively configurable, so they need a manual that begins with "how to read this manual". The workshop analogy builds on a false premise of low configuration equating to underpowered function. A pro will use a lot of different speciality tools that have no or minimal configuration, vs. a Swiss Army Knife that is mediocre at everything. In the same way, Unix-style workflows are very "shoot yourself in the foot" stuff, but formal configuration of each tool is minimal. The best thing a complex application can do is be a general-purpose programming API at its core, with common workflows surfaced as a polished, simpified UI. Each of those workflows is its own application, with internal developer documentation to orient someone who wants to hack on it. Then the 80% cases are solved by default, and the 99% cases("this thing doesn't let me configure x") are solved by copy-pasting the application code and modifying a single line based on a Stack Overflow answer. And everything beyond that, you had to code anyway, so you enjoy a real programming environment with documentation instead, and hopefully a hook into the broader ecosystem so that the API is available throughout different coding environments. Sadly, almost no application intentionally evolves in this way.

KayEss 11y ago
AutoCAD always has. The GUI is really nice, in that it understands how to build the LISP commands that actually implement the system. You can put in a template LISP command and tell it where you want a 2d point, or a distance and the GUI collects these and fills in the values. It can even do embedded calls to generate these from other things. It's extremely flexible and allows you to arbitrarily build new commands that are easy to use. I automated a workflow for a drafting studio I worked at in 1989 and reduced the time taken to complete a drawing from three days to three hours just by writing new LISP commands for all of the most common things we did and wiring them up to the menu on the tablets we had.

Kalium 11y ago

> So where does this leave complex, professional-level applications? Nowhere. According to the rubric set out here, there are no such things. They aren't applications at all. They're something else, something different, and compilers should be just as simple as Fart Noise Maker 3000.

jonathankoren 11y ago
`gcc foo.c` gives me a working executable. That's pretty simple, and guess what? I didn't have to configure it at all! The idea that "professional-level applications" (whatever those are) should be shipped in a non-working state is absurd. The fact that Fart Noise Maker 3000 should should be shipped in a non-working state is equally absurd. Seriously, if I updated Babel and it suddenly was broken, I would have said, "Fuck this shit," and deleted it. There's just no point even trying to figure it out. The previous version worked, and life is too short to deal with this type of stuff.
- Kalium 11y ago
  I use lots of professional-level applications that do simple things - like proxy connections to other applications - and require configuration before they work for my needs. That's because their nature means they cannot function otherwise. To expect that, say, a web server knows my need to serve a particular file from a particular directory a priori is absurd. But according to this rubric, I can and should expect things to Just Work. Does this mean I should expect pgbouncer to automagically discover what server it is to be pooling over, and that if it doesn't it's broken? It's silly. Real tools are often more complex than drool-proof iOS Apps. We do ourselves a grave disservice by pretending otherwise - or even by pretending that this is desirable.

bpchaps 11y ago

I think with professional level applications, the same thing can be said, but with a shift in gradient. Why wouldn't it be? I've been working with logstash a bit lately and... oh my god. The documentation is outdated, the initial examples have examples without explaining core principles, the log messages are almost useless, it takes about five seconds for the damn thing to even /check if the config is valid/ and holy mother of god if I see another line saying that something's been deprecated..... Also for the love of said god, when a bug report is filed and the dev needs to explain in multiple paragraphs why something undocumented is actually feature, not a bug... there's something truly awful. https://logstash.jira.com/browse/LOGSTASH-1348 https://logstash.jira.com/browse/LOGSTASH-1348 I can understand how these things happen, I truly do. But for something as widely used as logstash? No! Bad devs! The simple fact that folks on stack overflow recommend to use two different grok creation tools to get logstash working properly (unless deprecation, because hey why not) is a complete and utter failure in my eyes. Also, while I'm at it. I worked for an HFT firm that started going towards the devops stack, which required an install of Logstash. Installed it everywhere... I got woken up the next morning that every single machine was running cripplingly slow and that the trade desk had to cancel all orders. Huh. I installed it, but I never actually configured any of it to run... Welp. A ps showed that logstash-web was running..... but with a 5 second uptime? Turns out logstash-web's configs come installed with a bad config file that caused it to RESTART OVER AND OVER AND OVER. It killed any core the start job was running on for a good 10 seconds and immediately came up on the next. How...... why.... no..... :( Thanks, Logstash. I seriously hope somebody from your team reads this article. You're in absolute desperate need of usability lessons. /rant