Prescriptive software is better than descriptive software
kilianvalkhof.com
kilianvalkhof.com
On the other hand, I like using my Remarkable because it's just for handwritten notes and annotated documents.
I wouldn't say that prescriptive is better than descriptive, or the opposite. As much as dislike the phrase, it depends. I want my fundamental tools to be flexible. But I don't want to waste all my time configuring stuff.
Absolutely not. Compare most WiFi connection UIs to WPA_supplicant.
On windows: 'connection failed'
On wpa_supplicant: 'associating... atempting authentication... getting dhcpc lease... dhcp timed out'
One says "sorry computer doesn't work" and the other tells you what you need to deal with the problem. Stop infantilising users, it's disrespectful and counter productive.
Yet another logically-vacuous emotionally-manipulative statement.
The equally-manipulative counter-argument to that is "You're not emphasizing with the users - how would YOU like for, say, government bureaucrats to give you back a bunch of technical gibberish instead of telling you how you filled out the form incorrectly in plain English?"
Use logic instead. I think that it's easy to build interfaces that are friendly to both power users and non-power-users - talk about the possibility of that using logic instead of trying to manipulate the emotions of others to shame them into agreeing with you.
All of the software I have ever used fits into one of three categories:
* Tipped in favor of power users and frustrating to laymen
* Tipped in favor of laymen and frustrating to power users
* Frustrating to both laymen and power users
If it's so easy, what's a good example of software that rides the line well?
EDIT: And even within this dichotomy both groups are pretty fuzzy. Is a layman someone who doesn't know how something works, or someone who just wants to do the basics? Is a power-user someone who wants to customize, or someone who wants to optimize?
> If it's so easy, what's a good example of software that rides the line well?
I agree with you that the GP was wrong to claim that it's easy.
But here is a way to get something better than we have, and that is, GUI control panels that read-and-writes the same text config files that the user can, and do so in a cooperative way. For example, if the grammar of the config file is such that there is NOT-more-than-one-way-to-do-it, then it doesn't matter if either a human or software updates the file.
and if you want the UI to squelch the noisy details of what's happening, that's fine, but keep the log and make sure it's easy to get to.
I think that almost every piece of software ever written is "bad", and that the majority is even worse at the level of "terrible" - so I agree with you!
I just don't think that contradicts my point.
I should clarify - "easy" meaning "if you think about it, it's relatively obvious what should be done". One of those things is good, pervasive, in-tool documentation - which takes a lot of effort, even if it's not a "hard problem" in the sense of being intellectually tricky.
> If it's so easy, what's a good example of software that rides the line well?
Firefox. Firefox is very easy to use as a non-technical user, and has a relatively high skill cap (used to be higher with XUL/XPCOM, but even now you can do useful things relatively easily with the WebExtensions model).
The reason why there aren't more examples (even things that I absolutely love, like Emacs) is because (1) commercial software development is optimized for selling things (at the expense of power user (and often layman) usability), (2) open-source software devs rarely care about user-friendliness and/or aren't willing to write good docs, and (3) neither group seems to have the presence of mind to do the meta-analysis about why existing software isn't good.
...or, so I claim. I'm willing to be shown that I'm wrong, and change my mind accordingly - but as the result of a nice debate and not some malicious emotional manipulation, like what the poster I was replying to was doing.
> Firefox. Firefox is very easy to use as a non-technical user, and has a relatively high skill cap (used to be higher with XUL/XPCOM, but even now you can do useful things relatively easily with the WebExtensions model).
I wrote my original comment in Firefox. I don't think that any browser can meet the needs of both groups.
A very non-exhaustive list of Firefox issues for laymen:
* URLs are fundamentally frustrating for laymen. Full stop. If your browser exposes URLs, it's a phishing-filled, typo-squatted, and incredibly confusing experience for the average person. N.B. I am against recent efforts to "kill the URL", though I certainly empathize with the desire.
* If a site has an SSL cert, it gets a lock and says "connection secure", and if it doesn't then there's a scary security warning. There are millions of sites that are fine to browse read-only in http, and there are millions of scam sites available over https. Again, note that I am pro everyday encryption, my issue here is to do with asserting (in)security on only the axis of whether a CA issued a cert to that domain name.
* The browser extension permission model is not at all useful. Benevolent extensions that use exactly the common-sense permissions they need show a big scary list of permissions. Malicious extensions often show the exact same set of permissions as a benevolent one. Imagine if your toothbrush, dental floss, trashcan, shower curtain and shampoo required you to individually confirm to the cashier that you want to buy them because they require access to your bathroom. And then imagine your dental floss got an automatic update to record video of you in the shower and upload it to pornhub. It's absurd that we expect the average person to navigate this nonsense.
Meanwhile, here's a very non-exhaustive list of Firefox issues for power users. Most of these are issues I have myself.
* The old extensions API has been removed and the new one is much more restrictive in what it can accomplish. There's still not a download manager or tree-style tabs extension that checks all the boxes I want, even though they existed in the past.
* It comes bundled with Pocket and Mozilla have shown a willingness to automatically install literal ads. For a TV show that I've heard is about computer security!
* I installed a web clipper application to clip markdown. Except that it's not allowed to save files anywhere but my downloads folder, so if I want to clip straight to my notes archive I have to use a symlink.
* The browser extension permission model is not at all useful. Sound familiar? It's absurd that we expect even power users to navigate this nonsense.
that goes both ways. if you show the wpa_supplicant message, my mother wouldn't even understand if she is connected or not. nor would she gain anything by that information. you just came up with the other side of the same coin of terrible UX.
>> On wpa_supplicant: 'associating... atempting authentication... getting dhcpc lease... dhcp timed out'
>> One says "sorry computer doesn't work" and the other tells you what you need to deal with the problem. Stop infantilising users, it's disrespectful and counter productive.
> that goes both ways. if you show the wpa_supplicant message, my mother wouldn't even understand if she is connected or not. nor would she gain anything by that information. you just came up with the other side of the same coin of terrible UX.
Yes, you need both. When I write error messages, I try to combine a "user friendly" summary with more technical information and a suggested action, e.g.:
"Wifi connection failed: dhcp timed out. Try reconnecting or checking the router's configuration."
If you don't communicate both, someone's going to be frustrated. And even nontechnical people who have no idea what DHCP is benefit from mentioning it in the message, since it gives them something to Google.
The worst example I run into is when you get a notice that someone has tried and failed to login to your Gmail/iCloud/etc account, it tells you to change your password in the helpful suggestions. Why would you do that?
Honestly, I think those people can't be helped. They're technically helpless and catering to them makes everyone else as helpless as they are, which is a net loss.
We don't say "those people can't be helped" about people who are blind or deaf.
Well, we shouldn't. Many web designers seem to feel that way, though.
How is an impenetrable technical error code less scary than a pithy description of the actual problem? Eg.
"Wifi connection failed: dhcp timed out. Try reconnecting or checking the router's configuration."
vs
"Wifi connection failed: Code -49291994. Try reconnecting or checking the router's configuration."
For a real world example: https://www.flickr.com/photos/daveward/69888365
I'm not talking about dumping a stacktrace or dropping them into a debugger.
> We don't say "those people can't be helped" about people who are blind or deaf.
We also don't gouge out the eyes of sighted people because blind people exist, either.
I've done a little end-user support, and this is a pretty optimistic take on what you'd get. It would probably be more like "It didn't work." in both cases. Maybe you'd get "there was an error message"
Q: What do you see on your screen? A: Nothing
Q: Try again and tell me what happens. A: It didn't work and I still don't see anything.
Many people have an automatic reactions to any kind of error or message. They get dismissed automatically. It seems that some people don't even realize they're doing it.
'not connected. more info: blah #32893289327". Microsoft did something similar with an error code that you could google. that was super useful for debugging. the error message was in laymen terms though.
Error IDs on everything, please.
If you're having a good day, you can get them to leave a pop-up error message open for long enough to read the whole thing on the third or fourth attempt. On a good day...
I learned VI on some UNIX tools my father installed on our DOS computer in the 90's. Then I learned Emacs in 2000 and have been tweaking my setup ever since. Sure, it's not perfect, every few years when I have some down time I will spend a day fiddling with things heretofore unlearned, but the general setup has worked well (and gotten better) for two decades.
How many other editors have come and gone in that time?
Is it? Or is it mostly the IKEA effect ("I spent time on this, so it must be valuable") and busywork?
Was anybody's choice of editor really a major point in their developer progress and productivity?
And so, even if I was born an expert vi user, I don't think I would have gotten any boost in productivity as a developer. Just my opinion though! :)
(Yes, I know how you can get vi editing in VS. I purchased a copy of ViEmu.)
Having used multiple IDEs and editors, from DOS edit/qbasic to notepad.exe, RHIDE from DJGPP, Visual Studio, Xemacs (briefly), Vim, Eclipse, IntelliJ, probably others...
Yes, some of those bring unique abilities that the others lack, that have an effect on the way I write software. Had I just picked one editor or IDE and never used any others, I would be much less accomplished. Vim, for example, is for me incredibly rapid at rearranging and replacing words/lines/regions of text compared to the others.
Sure, but how much of that clerical work is relevant to programming, where a rate of say 100 lines per day is a major achievement, and it's usually much less? Even if one needs to delete/copy/re-arrange 1000 lines in order to get to those 100 (and usually it's more like 30-50 per day than 100 anyway), it's still a tiny part of the time.
In any case, I've seen great coders, from Brian Kernighan and Bill Joy, to Linus, Carmack, and Persson using whatever from Vi and Emacs to Visual Studio and Eclipse, and still getting shit done...
In my personal experience, before i started using spacemacs i would postpone re-arranging code when i was busy coding something useful. Pushing all the cost into an afternoon of _just_ rearranging code.
Besides not having a very 'productive' afternoon, the costs would linger because i need to update my mental map of all the stuff that moved around.
Now, most rearranging is a couple of key strokes away. I'm not sure what i would do in another IDE. I would probably do the rearanging as soon as required, because I've learned my lesson.
But moving my hand to the mouse and clicking multiple buttons while typing new file names and dragging my mouse over pieces does take a lot of flow out of the session.
I don't understand why people equate IDEs with mouse interaction. All major IDEs, from Emacs to VisualStudio, have key combinations for anything you can do. It's fair to say some key combinations are better in one program than another, but there is no reason to imagine that using an IDE means you must also use a mouse. The mouse is always an extra option, not a requirement.
And there are code modifications that an IDE can do for you cheaply at the press of a key that would take hours of tedious, error-prone manual work, even with fancy vim fingerwork. Even the lowly 'Extract Function' already can save a good half an hour for more complex cases. And modern IDEs offer things like passing a parameter down through a long call stack in all places (a calls b calls c calls d calls f, and now you want a variable in a to become a parameter in f), with guaranteed 0 manual intervention. Or extracting an interface out of a class and patching all callers.
Not to mention all of the code exploration options, such as IntelliJ's 'Dataflow to here', which finds all of the code which is responsible for a variable's value throughout your entire program (or the dataflow from here operation, which finds how a value set in this function is used further down the call stack), stopping only at IO (so if a.foo() reads a value from a file and stores it in a field that is read in a.bar() which puts it in a dictionary, where it is read by baz() which adds 7 to it and prints it out, you can ask for dataflow to the variable being printed and it will find that it was read from some file in a.foo()).
Wait, what? 100 lines per day is an achievement?
I'm honestly curious in what branch of SW development this happens. I'd assume something that requires formal proof of every piece of code ever written?
Most. It is based on some well studied and established averages, anywhere where it's actual core programming (ie. not counting churning out boilerplate html/css/CRUD code N times for the same/same-ish functionality).
Actully 100 lines/day is on the optimistic side:
"Capers Jones has compared many methodologies (RUP, XP, Agile, Waterfall, etc) and programming languages over thousands of projects and determined that programmers write between 325 and 750 lines of code (LOC) per month"
I believe you are picking a point that wasn't my main one. I may not have made it clear, but in my view, I'm going to be using a tool (in this case, an editor), so if I can pick one that is powerful and will be around, it's a net win to learn it. I'm going to learn it anyway (through use).
Emacs is insanely powerful and it's not going anywhere, and I'm fairly certain it was a major point in my progress and productivity, and it continues to be.
You want libraries and platforms to be descriptive, and end-user functionality to be prescriptive. They're different types of software.
you proved the article's point with these examples. If you want to write software that can become a sustainable business, don't do what linux and emacs did. It only serves power users and other businesses who will sell services.
I also prefer descriptive tools (I hate rails/django), but I acknowledge that descriptive is typically worse UX unless the user is a power user.
Serving the most users (ie. NOT power users) is usually the best economic decision as well.
The end goal of any piece of software that wants to deliver actual value is to turn its user into a power user. Power users aren't born, they're made - made through repetitive use. Software that doesn't give a path for the user to grow and become more proficient is software that literally wastes their limited time they have on this planet.
As usual, what's the best economic decision and what's actually good are aligned here only so much that you won't get laughed out of the room for proposing they're the same. But not much more than that.
now who's entrapping who?
you think its practical for every piece of software to be a massive time sink?
> software that literally wastes their limited time they have on this planet.
There's a saying "linux is only free if you don't value your time", now you're saying that software that takes MORE time commitment saves you time? C'mon, take off your engineering hat for a second.
1) Actual value to people is mostly created in software that's being used repeatedly. The tools people use for work, to run their errands, and to communicate.
2) For any tool that's used repeatedly, if there's no path for the user to grow ever more proficient and efficient in using it, the tool is wasting that user's time.
> now you're saying that software that takes MORE time commitment saves you time?
No, I'm saying that less time spent on using software to accomplish unit of value is better. For software used repeatedly, this is achieved by learning to use the software better - and that can only happen if the software offers room to grow, and isn't just a Fisher-Price toy.
I'll do you one better. for software used repeatedly, it is better to completely automate the task (if possible). It sounds like your goal is to empower users. The higher goal, imo, is to unencumber users.
I see you're a Lisp man so I get where you're coming from (elegant extensibility — I'm an OCaml + F# man myself), but IMO the beauty of software is the ability to remove human interaction, not increase it. And any interaction that is unavoidable should be minimal.
Innovation is the ability to reduce to the minimum viable components without sacrificing functionality.
--
And I do agree! Software that can completely automate the task is the best! It's just that it's really hard. Where we could've done this, we've already done this. What remains is software dealing with tasks that cannot be fully automated[0] - tasks that require human decisions as input, decisions the software can't reasonably guess in advance.
For such software, there are two axes of interest here: how many decisions are there to be made, and how complex/consequential they are. These are inversely correlated to some degree - the big decisions (like how to repartition your hard drive or whether to sound a missile alert) tend to not be made very often[1], and they benefit from UI that trades safety for speed. My focus was the other type - the one that requires lots of individually small decisions. The type that's used repeatedly throughout the day or week.
In such software, you're guiding the computer towards a particular outcome, or a series of outcomes. The decisions involved are simple: what letters to type, when to send a message, what vertices to select, what transformation to apply, where to position items, what columns to sum, etc. The computer can't guess your goal here - often you don't know the goal yourself. You're in a feedback loop with your work, mediated through software. And it's best if that loop can be as tight as possible.
The limit to how much this loop can be tightened is the level of comfort of the user. Initially, they'll want to make every step manually. Type every letter. Click on every icon (making sure to first hover and read textual help). But soon, it gets tiring. People don't think about tasks in terms of "type 'hello<ret>'", "look where the column starts, where it ends, type '=SUM(A2:100)<ret>'". They think in terms "say 'hi'", "sum this column", "make this stuff be there". Sometimes we can predict these, we can put "smart compose" or a sum button in our software. We can add support for clipboard, autocomplete. Thus starts the "featuritis", so dreaded by modern web UX people. They're often misunderstanding the problem as having features, but the problem to solve is how to reveal the features at the right time, when the user is ready for them.
From there, there are two ways to improve still. One, ergonomics. At some point your user will be tired of having to click around to do everything. They make decisions much faster than they can input them. Software is best when it can operate at the speed of thought[2]. So why not add discoverable keyboard shortcuts? Users who reach this stage will be happy to discover they can input their decisions faster, if they don't have to hunt buttons in the UI. Their level of comfort will rise too, because they don't have to break themselves out of their flow[3]. For more advanced users still, here is where tuning enters the picture. Predefined ergonomics may be almost right, but not quite. It's nice when the user can change the defaults to better suit themselves and their particular work.
Two: composition. At some point, the user grows from thinking about each low-level decision individually to thinking about them in aggregate[4]. In a way, they DRYed up their steps into a procedure. The software thus can get better if it lets the user define this procedure somehow, and then invoke it on demand. In the limit, this means coding, but for most cases, it doesn't have to. At the very least, it means batch operations. If the user has to make the same few steps on a series of items, let them input these decisions once, and apply to the selection. This little feature can transform a work day[5]. And you can go further. Could the user save their search query? Could they combine that saved search with the batch feature? Could you turn "selecting a query and applying batch operation to it" into a higher-level batch operation[6]?
Will everyone need all such features? No. But various users will find themselves using some of them - the ones that fit well with their needs and their level of comfort. The job of UX design is then to make users more comfortable with advanced features. Making them easier to discover, test and learn, so that they can save more time. But for that to happen, the software first needs to have those features. It needs to have the room for users to grow.
--
[0] - Without human-level AI.
[1] - Except. At least when it comes to dealing with computers, a decision that's very important for your personal machine may be totally inconsequential for a cluster of VMs - so as a software author, you may want to have an "escape hatch" for batch, noninteractive work. Noninteractive work is something that comes up in all types of software, as it can let a tool gain many more use cases.
[2] - Anything less is, again, wasting user's limited time on this planet.
[3] - I realize I'm just making claims without providing any citations. I don't have any, at the moment. One of these days I'll dig into HCI literature. In the meantime, I'm just hoping everyone here both knows this from their personal experience and seen this with non-tech people at work.
A familiar example that jumps to my mind is interacting with various clerks and officials. A cashier using a good ol' keyboard-based POS system, the one that runs in DOS, can input your order and print your receipt while simultaneously holding a conversation, and be done faster than it takes you to find your wallet. Similar cashier with a modern browser-based POS system will click around screens in full focus, and have you wait a minute or three before they can update inventory. It's also interesting how stores where throughput matters - e.g. supermarkets - end up wiring their modern POS systems to keyboards.
[4] - Much like every driver has a point at which they stop thinking consciously about pedals and steering wheel and gear lever, and start thinking in terms of joining the traffic, changing lanes, overtaking - and eventually they just manifest their will through the car, while their hands and legs move themselves.
[5] - I was once asked to help some people at a sales department of a small e-commerce company to update some of their listing on an auction site. It's a job they'd be doing every couple days, taking three people an hour or two. I poked around their management panel a bit, found a very well hidden button that allows doing batch updates, and showed them how one person can do that task in 15 minutes. How much time they could've saved if that button was a little bit more discoverable?
And I'm sure that, the way it was placed, some "data whiz" at the management panel's vendor will look at the analytics, notice people don't click on this button much, conclude that users must not need it and decide to cut the feature out. The self-fulfilling prophecy of modern "data-driven" software development.
[6] - And yes, ultimately, could you let the user just write code, and also expose the functionality in CLI for headless operations? These two things will definitely be niche, but will enable completely new use cases, potentially broadening your market. How many CLI scripts already exist on Github to do a half-assed job that could be done by popular software if the vendor thought about letting it be driven headlessly by an external script?
This also assumes that the time you invest in learning the software will be offset by productivity gains, which seems extremely unlikely for the majority of users assuming the software is non-trivial.
There is also risk associated with learning the software. What if you begin to learn it and then for some reason you stop using it? You've just wasted a whole lot of time.
You can repeatedly use software (I.e. daily, monthly, yearly) for short periods of time or for specific tasks. That doesn't mean you'll be using it all the time though.
I think most users fall into this category rather than people who use it "all the time". A lot of the time people just use software to get the job done and aren't engrossed in using it.
If I can improve my efficiency/revenue/whatever metric more by leveraging something other than this software, why would I waste my time learning how to use the software better?
Yes, and perhaps I should've clarified that I meant "repeatedly" as in "couple hours or more a week, on average". With an important caveat that software which is used "for short periods of time or for specific tasks" by some people all too often is also used all the time by other people. E.g. I use Word or Blender for about an hour a month on average, but there are many people who spend eight hours a day, five days a week in front of them. It's bad if you handicap the former for the sake of the latter.
> A lot of the time people just use software to get the job done and aren't engrossed in using it.
The difference I'm trying to focus on here: if you're using the software once, to do one-off job, there's no point in you investing into learning it. But if you're using the software to do a job done on a regular basis, you'll eventually start looking for ways to spend less time doing that job. It's nice if software offers such ways, and guides you towards them.
> If I can improve my efficiency/revenue/whatever metric more by leveraging something other than this software, why would I waste my time learning how to use the software better?
Fair. I'm explicitly talking about situations where you can't. You have a job to do, this is the software that lets you get it done. If you can use different software to do it faster, then of course you should use it.
For example, as a programmer I occasionally need to prepare presentations, in which case I use PowerPoint because that's what the company bought. I use probably less than 1% of what PowerPoint can do, and I wouldnt lose anything at all if I were given a program that did exclusively that 1%. I would in fact gain some productivity by having to browse through fewer options. I have no intention and would gain nothing by becoming a PowerPoint power user.
One doesn't have to exclude the other. You can present a gradual onramp but make advanced features available and discoverable.
> I use probably less than 1% of what PowerPoint can do, and I wouldnt lose anything at all if I were given a program that did exclusively that 1%.
That 1% solution is called Google Office Suite :).
You obviously don't need PowerPoint much, and your use of it isn't really creating much of value either. Contrast that with people who use PowerPoint for most of their working day. Ignoring for the moment the difficulty of quantifying value of managerial meetings, it would be really bad if Microsoft one day decided to ignore the people who use PowerPoint extensively, for the sake of greater amount of casual users.
That's the kind of ass-backwards "economic thinking" I'm complaining about. I get where it comes from - pursuit of growth at all costs. It's a disease in software industry. Instead of great many tools optimized for the needs of diverse audiences, the "servers most users", "best economic decision" mantra is to create lowest-common-denominator toy that can gain userbase fast, and suck out oxygen from the market.
The other approach is to create two or more programs: one for (each) basic use case, that can't be used further, and one that supports the gamut of advanced use cases, with UX optimized for efficiency.
The first approach would be ideal, but in my experience it is extremely difficult if not impossible, just because of UX considerations - often times, what is efficient for an expert will look arcane and confusing to a basic user.
The second approach is more promising, though it also has its problems of course - most notably, the fact that the advanced program can easily become very difficult for beginners who do need/want to become experts.
- The basic use case is the only one that gets developed :). That's where the money is, that's how you make userbase grow fast, and that's where my complaint about following "best economic decision" comes from. The oxygen gets sucked out from the market.
- The software may only provide for base use cases, but that doesn't mean it has to be bad at it. The bar for improvement is really low here. It's fine to be focused, but you can still leave room for users to grow - to get better and faster at using the existing functionality. So e.g. you don't need to turn your photo filter app into the next Photoshop, but you could add keyboard shortcuts to all operations, allow users to apply the same operations to a batch of photos, and let them save the result in a commonly understood format (instead of just proprietary one).
Shaping the learning curve is always tricky, but there's plenty of room between notepad.exe and Emacs. We don't have to build software only at the extremes.
(Related: simple software for basic use cases is half of the hallmark of UNIX philosophy. The other half is that software needs to compose well. While traditionally applied to niche CLI programs, these principles work well in general-purpose GUI applications too.)
The huge issue with components that don't give you much choice is that they do not compose well. You find two components clash on some decision and neither has any mechanism to resolve the issue.
This is frequently the case with "frameworks", which tend to want to control all aspects of your application.
Does this make your life simpler? Sure, but only if your application is exactly or very closely to what the author of the framework envisioned.
On the other hand there are "tools/utilities". These can fit same role/functionality as "frameworks", but they are not intrusive, don't tell you how to put your application together. Rather, they give you tools with assumption you will know how to use them.
Does this make your life simpler? SURE If you have non-standard application and you know what you are doing you want to compose your application from tools that do not demand too much from the structure of application, dependencies, etc.
If you are novice developer it might be temporarily useful to use more prescriptive tools. You don't know how to put stuff together so you might just as well learn how others do it.
If you are advanced you will know what to use. If I know I will be working on a very standard application I might just as well use something that takes care of it all for me.
Of course, I think this whole idea is basically flirting the same thoughts as "sensible defaults" and "paradox of choice". Which is somewhat of an ironic fight between having all of the options, but not requiring all of the options. A hedge, if you will, around what you may want to do in the future.
What I interpret "prescriptive" to be is that the message returned to the user on failure should give some hints how to make the program succeed. Because there are more ways to fail than the program author could think of, or more than fit on a screen, it is opinionated which advice to give then (a subset of all known and unknown possible fixes).
I always tell my coworkers, an error message is a call for action, not an out-of-jail-I-just-stop-here card. The better you guide the user, the more efficient she can use our software.
I think this is the same "mechanism, not policy" debate repackaged, and I certainly think mechanism is better than policy, where the author of the post thinks otherwise.
That said, I think that going all-in on "mechanism, not policy" is a mistake too.
I believe there is a middle ground: focusing on mechanism, but providing a sane default policy that lets the user get stuff done fast and change things later if they need to.
I wrote more about this idea in https://gavinhoward.com/2021/03/lessons-learned-as-a-user-1-... .
I agree with this.
I see parallels to a lot of frameworks, languages, libraries, etc: the "getting started" guide is fairly simple, but then to do a "real" thing with it, you need to basically throw all that away and learn a whole different system.
The other mistake a lot of systems make is abstracting away the complexity with defaults (aka "magic"), but making it so if you do want to change one thing you have to learn and re-implement the entire configuration yourself.
In both cases, it's the learning curve that is important to think about: going from usable defaults (beginner) to customization (expert) should not be one giant all-or-nothing step.
As a physical example, I can't remember the last time we had to educate people on how to "pump your brakes" in the rain. Turns out, there are flat out better mechanisms to control for some of these things. I suspect many lane assist technologies and other mechanisms to eventually grow to eclipse environments that lack them.
But, bringing that back to the software world is hard. There are things that we don't give a second thought to in a lot of what we do. Endianness is an easy example of something that you used to not be able to avoid. How do we get more of our concerns across that line? Can we?
However, I still have learned how to pump brakes in rain, and I taught it to my wife. The reason is that the better mechanism, anti-lock braking systems in this case, can always fail.
Joel Spolsky had a whole post about this: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... .
If we only teach the happy path, we are setting ourselves and everyone else up for failure when the happy path fails, which it will.
As another counterpoint, there is so much automation in modern airplanes that pilots are relying too much on the automation and losing their basic airmanship skills. (https://www.nbcnews.com/news/us-news/airline-pilots-depend-t...)
I think the same problem is starting to show in all of the assist technologies in cars. People are starting to rely more on those technologies than they should.
Basically, at some point, putting more concerns across the line is a bad idea because we will eventually lose the ability to handle things when they go wrong. We also lose institutional knowledge. (https://www.youtube.com/watch?v=ZSRHeXYDLko)
Other examples include monoculture of crops. Generally, not a good idea. Happens wherever it can, though.
That is, I agree with your points. I just have difficulty thinking we have the full picture covered. :(
Have you seen the commercials where someone is driving and almost gets everyone killed by taking their eyes off the road. The system slams them to a halt, barely saving them, and the parent happily smiles - family safe, nothing to learn here. In one commercial, the parent is supposed to be teaching their child to drive.
These driving aids should work differently. If they ever have to emergency-brake to save you they should immediately activate a small packet of thermite in the ECU, rendering the car into a brick. You proved you can't use it safely so you shouldn't have it.
It would be different if these devices worked, but they don't. They just tell you that your lack of skill is okay.
The title aside, I don't actually disagree with anything in the article. I've had similar experiences to the author with tools like linters and formatters. Agreeing on configuration for them can waste a surprising amount of time.
As time goes on, I do find myself more willing to change to fit my tools rather than change them to fit me. Often, I find the creator of an opinionated tool has more carefully thought through their opinions than I have anyway. Even if they haven't, tools like gofmt showcase the power of consistency for consistency's sake.
That said, I use a tiling window manager and I'm pretty insistent that control belongs where caps lock normally is, so clearly I'm not entirely bought in to my own rhetoric.
“Descriptive” software accelerates exploration, and “prescriptive” software is a lower-complexity implementation, either a prototype or optimized for specific purpose. While “prescriptive” normally offers better performance (for the purpose it is designed for), “descriptive” tends to linger around longer because of it flexibility, but neither is permanent anyway. Making a progress is merely going through those two back and forth again and again. There’s no end.
We hire software to do jobs like how we hire people to do jobs. Both become better when they share their opinion and help us decide how to fix or approach issues.
I think that is why things like VSCode, emacs framework, get popular. Most of us don't want to spend a long time configuring the tools, but just get the job done. For most of us, a sane default is more than enough.
Are you sarcastic?
Edit: Extended quote
My favorite example of a good balance here is React's 'dangerouslySetInnerHTML'. Clear opinion, check, but you've got the escape hatch you need.
> It's great until it's not and then you're kinda screwed
Do you have some example? Because black frees us of any argument over coding style in merge requests and this is great. It helps us focus on the important things. I've seen places where I don't quite like what black enforces, but this is very rare and it is a matter of taste and you get used to things, so meh.
In contrast, standard (for JS) seems opinionated at first does not come remotely close and leaves many things without opinion, and unfortunately we don't have the same opinions and tastes, so we regularly argue over them and this is a waste of time.
I don't actually quite like standard's rules but since this is what we use, I wish it were much more opinionated (over brace position in React files, line length, how obj.hasOwnProperty should be banned, how to declare methods in React components, how order imports should be sorted alphabetically, or which variable we can deconstruct…).
I hear this all the time, along with 'Juniors will be confused' but it never seems reasonable. Sometimes I line up variables:
name_field_id = 0x01
address_field_id = 0x02
Sometimes stuffing a method on one line is best because you get ten boilerplate methods on ten lines and can see the similarity, other times that's just silly and they'd be best spaced normally.
Sometimes I use a rightward assignment { ... } => x because it fits the code better, leaving the reference to x right next to the next statement which will use it.
> so we regularly argue over them and this is a waste of time.
Strange disfunction. It sounds like your team is too opinionated to allow other opinions.
> I wish it were much more opinionated
Suggest turning on more rules but leaving them as suggestions. Where any reason to not follow them is enough. You do want to make sure people have some reason to make sure they aren't just leaving a mess but it's easier to get them to care about style if they have a say in what clean looks like.
As an aside, part of the issue is comfort with the tooling. If I have to work in someone else's file and I hate the syntax and it's a big deal, I first run the linter to make the code look my way, make the change, run the linter to go back to their style, squash it onto my change, and rebase away the first lint. Work done, no problems dealing with someone else's style - even in the case that it would otherwise be a problem. I never have to, but because I can it doesn't bug me.
I think the ideal is that the software is as configurable as it needs to be in order to be useful to the people that use it, but that there's a standard configuration with sensible defaults.
But then you find articles like this, which take it to the point of pushing opinionated software principals as its own opinion, framing such design as universally "better" and that that is how software "should" be written... I find myself unable to just sit idly by and not respond to such a thought--seeing where it is on the HN front page--without at least some kind of rebuttal, as it is a thought that I find actively harmful for trying to not just invite people to consider their options, or think about the tradeoffs in what they are trying to accomplish, but to try to actively discourage people from building software that adds value to the world in the form of doing something someone other than the developer wanted done.
The world of this article--where everything is "use it or don't"--is a world full of wrong-handed scissors, one-size-fits-many clothing, single-station radios, and "no substitutions" menus that are simultaneously prix fixe. This is a world where people who show up saying "I know I could be X% more effective (or even simply happier) if only your software did Y" are told "you don't know what you are talking about; and, even if you somehow did, you should learn to make do without as that's the austere thing to do". This is a world where not only is everyone working at merely an average level of efficiency, but no one gets to enjoy the art or experience of doing anything, as a world without color is supposedly a world with less stress.
To enter the same narrative frame as this author: if I hire software, I want that software to be working for me. I often do know what I need to be effective, and I'm hiring software to do that job: if by any of the developer's hubris, incompetence, or laziness, the software is incapable of doing the thing I wanted it to do the way I needed it done, I'm going to either hack their masterpiece until it works the way I want it to, or I'm going to fire it and find (yes) a "better" piece of software. FWIW, in this way, I'm lucky: I can build my own software, and I can modify your software (even if it is closed source!)... not everyone can.
And that's where I feel like this is most dangerous: that software developers are effectively building the world for everyone else, and when we drink the kool-ade of these "opinionated" manifestos, we begin to believe that we are best able to decide how things should work for everyone: that there is one way to best edit videos, or write documents, or compose music. We should listen to our users--even if they are other developers--to learn what would empower them and make them effective, and then add enough settings (or extension points or whatever: "even software should have screws"! https://www.youtube.com/watch?v=ReKCp9K_Jqw) to let them feel like themselves.
Because the alternative is just sad :(. Again: there is a time and a place for being opinionated, and it isn't that I'm saying that concept is always broken... but there is maybe nothing more infuriating than something that is almost perfect, and the decision to resist having settings or options in your software because of a claim that they are some kind of cop out instead of an admittance that people have different needs, interests, or understandings, is the kind of "opinion" I have opinions about. Remember: "Opinions are like assholes: everyone has one, but they think each others stink." -- Simone Elkeles
I'm a big fan of Prettier for this very reason. It just works. It's decent. It lets everyone get on with writing software. If a project has ESLint, there's a high chance I'm going to be talking about semi-colons, or looking at oddly line-broken code. Someone else is going to notice it too, and want to fix it. Then we're all talking about the Airbnb config and what customisations we're going to make.
In recent years I've:
- Quit using Colemak and gone back to Qwerty
- Stopped using vim and went back to IntelliJ
- Stopped using custom fonts, themes and just stuck to defaults
- Become more selective about what plugins I use
And I'm suprisingly (or unsurprisingly) more productive.
People do this all the time.
s/ ...matching regex... / ...replacement string... /g
[1] https://www.gnu.org/software/sed/manual/html_node/The-_0022s...
https://www.gnu.org/software/sed/manual/html_node/The-_0022s...
Though, I am excited about Roslyn Analyzers and how dotnet seems to be pulling together a language standard LINT system. https://github.com/dotnet/roslyn-analyzers
No matter how good your prescription system is, it is going to be a bad fit for some programmers use case.
I've always thought if it in the context of the Pareto principle.
80% of the time people will use the defaults but 20% of the time will need more customization.
Take for example Apple vs. Microsoft/Android. The PC-environment is legendarily descriptive. But the Apple environment is not prescriptive. It's just "intuitive" (for those who buy into it), or, less charitably, it hides the descriptions while at the same time not being explicitly prescriptive either. What do we call this Apple system? It's neither prescriptive nor descriptive.
To me that was a wonderfully discoverable and seamless experience.