Zero configuration software (and much more)

[Preamble, 2023-07-24: Over the years, various problems have come up with folks I mention and/or link to in this article.  Some of them, I wouldn't link to or mention today.  I'm going to leave this post as-is for now, but I thought I'd just mention that I'm aware of problematic behavior, of various sorts, and... yeah.  Please do not construe this post as an endorsement of anyone else's work or personage.  It's just the artifact I created 11 years ago, before having heard and/or internalized those issues (though at least one of them I had reason to be aware of in 2012... sigh).]

Paul Graham once said:

If you think something's supposed to hurt, you're less likely to notice if you're doing it wrong.

Well, guess what: I'm strongly of the opinion that a whole lot of people are doing it wrong. Presumably because the following corollary (my own words, this time) also applies:

If you've been doing it wrong since you can remember doing it at all, you're probably inured to the pain.

And I, for one, am of the mind that allowing oneself to become inured to the pain is doing everyone (yourself, and everyone else, too) a disservice, and that standing up for pain-free things is a good thing.

Now, this could apply to all manner of things -- for example, in a great TED talk by Dan Ariely, some great observations are made (also viewable on YouTube) about pain treatment in medical settings.

Meanwhile, for this essay (in this sense of the word essay), I'm going to focus on something that I have more direct experience with:

Software, and especially the development thereof.  Note, though, that while I'm talking about the development of software, on the one hand, I'm also talking about its effect on end users, whether or not those end users are also developers.  So the software I'm talking about could be anything from a custom piece of software for some kiosk somewhere (or order-taking software at a restaurant, say – i.e. something that is used by people whose main business it is to do things completely other than dealing with software), all the way to programming languages (which of course have the primary audience of software developers – while also being written by them).

So...

I am of the opinion that there's a whole lot of pain in the realm of software (the entire realm, as outlined above) that people just put up with, and that our world could be a whole lot better, if we (all software users, with a bit of special attention on developers, since they have a more direct ability to do something about changing the software itself) would just stop putting up with it.

That's Step 1: Stop putting up with software-induced pain. So then what? I'll get back to that.

But first: You know, actually, some of Ariely's observations might very well be useful in explaining why we do put up with it. (And I'm of the belief that knowing how and why something happens is one of the most powerful tools available for trying to prevent something from happening – or encouraging it to happen again, if that's what you're after.) For example, he says (emphasis mine -- though it mirrors some hand gestures in the video):

It turns out that because we don't encode duration in the way that we encode intensity, I would have had less pain if the duration had been longer but the intensity was lower.

I think that, for most of us, the intensity of pain of dealing with software annoyances is relatively low.  So, given the above findings from Ariely, we are able to tolerate it for hours and hours, days and days... months, even years – perhaps in some cases without ever even really noticing (at least in a conscious and remembered way) that it's painful.  Because the pain isn't that intense – it's not physical pain, after all, and hey, a lot of us are getting paid for experiencing it (because we're paid for jobs in which we basically have to deal with it), so it probably nets to being a positive experience for a lot of people – we're able to tolerate it pretty well, even if the duration gets to be quite extensive.

I think for me, though, the pain is more intense. I don't know why that's the case (and I don't think it matters, for the purposes of this essay), it just seems that I react differently to annoyances in software than other people around me. It seems to bother me more than a large percentage of the people I interact with.  I don't have any hard data to back that up, it's just an impression I get when I watch people interact with software, and sometimes even ask them about their interactions.  Things that drive me bonkers, they'll brush off, even when I ask them if it annoys them.  It does, they might even admit, but it's "just the way it is".  Ugh.  For me, such things are much harder to ignore.  It hurts when something is slow, or requires me to jump through a bunch of hoops to get it working the first time, or whatever.

I consider this to be a virtue of sorts: it becomes one of the things I can give back to the world: experiencing the pain so that I can try to help make the pain go away.  In this case, by drawing attention to it, with this blog post.  Consider this my little attempt at a bit of consciousness raising (and when you're done with this post, if you still want more consciousness raising, a bit more (in two parts) consciousness-raising, on some topics related to each other, but quite unrelated to this essay – what can I say, I have strange (?) tangents of thought, sometimes).  Anyway, my attempt at consciousness raising is done in the hope of encouraging others to join me in my efforts at finding and creating fixes and improvements – to software, software development paradigms, etc – that will benefit... well, ultimately, the hope is to benefit anyone that ever uses any software, anywhere, ever.  Grand plans.  Don't worry, we can start more locally than that.

Let's call it Step 2: Try to find ways to reduce the pain. While this does especially apply to software developers, I do not limit it to that audience.  Anyone reading this is almost certainly someone who uses software to some degree or other (unless someone printed out this page for you, and even then, you're an indirect user), and if we all work together at trying to find solutions, we'll do a lot better than than any of us can do on our own.  So I'm writing this for the non-developers, too – and, developers, please: do go and solicit (and/or welcome) their help.

Exploring further, I notice that Ariely also observes:

It turns out it would have been better to start with my face, which was much more painful, and move toward my legs, giving me a trend of improvement over time, that would have been also less painful.

He's talking about taking bandages off of burn wounds. Software is, of course, different.  But the principle, here, is this:

A decreasing level of pain is remembered as less painful than the same initial level of pain just stopping. I.e. the latter case has less "total pain" (the area under the curve of intensity over time), but a higher intensity of pain at end (because the pain suddenly stopped) of what we identify as the experience (which we presumably mark as a separation of experiences when the pain simply stops), and the greater "total" pain is remembered as "less painful".  Hmm, I think I'm not doing a great job of explaining it... Here: another TED talk, Daniel Kahneman on experience versus memory (also on YouTube), does a better job.

Anyway, it seems to me that this idea still applies in the world of software pain: If we can find some workaround (as we so often do) for our pain, the intensity of pain decreases, and so we remember it as having been less painful than it actually was at first.  Someone who faced exactly the same problem, but failed to find (or gave up on finding) a workaround, would remember it as much worse.  Even if you spend extra energy and experience extra pain in trying to find a workaround, you'll still remember that as less painful than the person who gives up!  (Moral to this story?  Don't give up, I guess.  But that's not step 3.  Not in that form, anyway.  We're not there yet.)

And let's dig a little deeper into the idea of a workaround (as described on wikipedia).  The description starts out simply enough:

A workaround is a bypass of a recognized problem in a system.

There's something in there, though: A recognized problem!  Guess what: If there's a "recognized" problem in something, that almost certainly means it's been "recognized" by more than one person – before it got to the point of having a workaround.  That means someone noticed it before, and didn't fix it.  Now, I'll grant that there are, at times, good reasons for not fixing a problem as soon as you notice it.  I do think, though, that taking that route creates part of the problem.  In fact, let's go ahead and define:

Step 3: Whenever possible, fix a problem as soon as you notice it.  The "whenever possible" part is an important piece, of course, and one might even weaken things to say "whenever practicable" or even "whenever practical", which leaves a great deal of leeway to say "it's not practical right now"... which I hope you'll rarely do – and when you do, it's because it's not practical for you to learn the things you need to learn in order to fix the problem, rather than that it's "not practical" to spend some time on doing the fix.  Well, and maybe this takes us straight to another step:

Step 4: When it's not possible to fix a problem as soon as you notice it, make some partial or unrelated fix, instead.  The idea here being to fix something (or make some progress toward a fix), because you noticed a problem.  While the motivation that the pain creates is still present.  Whether that's adding a message to the software about it having a problem, or adding something to a to-do list somewhere (though be careful with that one... it does need to be a TODO list that actually gets looked over and has things checked off of it for this to be enough), to just fixing something else that's been on the back of your mind but un-done, because you don't know how to fix this new thing, but are perfectly capable of fixing something else, and just haven't done it yet.  Better to fix something, even if it's unrelated, than to just continue living in the current state of pain that exists, when that's changeable.

And maybe you even come up with a workaround.  After all:

workarounds are frequently as creative as true solutions, involving outside the box thinking in their creation.

So I have nothing against finding whatever way you can to help reduce the pain.  A cast doesn't actually fix a broken leg, after all, though in that case it does help the healing process along, by protecting the healing process in some way.  If you can shield a developer from pressure by creating a workaround for software that you don't know how to fix, hey, that's useful.  Just remember:

Step 5: When you create a fix or workaround, be sure to share it.  It's not helpful to anyone else unless it's shared.  And maybe by sharing it, you'll give someone an idea about possibilities for how to fix it.  One great thing about open source (and especially these days with social networking and source code getting together on things like github) is that sharing is often possible.  Sharing is the way to help reduce pain for others.

Just remember, though, if you're doing workarounds, that:

A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed.

 So, do try to do the "genuine solution" when you can – in fact, creating a workaround may be specifically be a bad idea, much of the time, because it goes directly in opposition to:

Step 6. Increase the pain.  No, I'm not after people being in more pain.  Quite the opposite.  BUT, I think increasing the pain temporarily can decrease the pain overall – because, after all, pain is a signal to us that something is wrong, and that we need to do something about it.  The stronger the pain, the quicker we'll respond – on the presumption that we've adapted the stronger pain response to things that tend to be more life-threatening.  Well, bad software (usually) isn't life threatening.  Not directly.  But, I do submit that it causes us harm – if only via the opportunity cost of every moment spent dealing with some ongoing problem, that could have (and might well have) been fixed, if it had only been more painful to start with.

So, if you're writing a C program, turn on the -Werror compiler flag -- make warnings be errors, so that you're *forced* to fix them, if you want to get a compiled program at all.  Stuff like that.  Make it hurt more, briefly, so that you'll be more likely to fix it.

Now, this may all seem like it's in direct conflict with Step 2.  Hrm.  It probably is, in a way.  I did mention this was an essay, right?  Well, let's see.  I guess that leads us to:

Step 7. Find cures, not band-aids.  Maybe not every single time, but do strive for this.


And now...

I want to get this essay out into the world.  I don't feel like it's "done" yet.  It's certainly not had all the editing that I could potentially put into it.  However: I started it several months ago, worked on it again maybe a month or two ago, and now I'm here again, facing lack of completion, and having lost a lot of the mental threads of where I was.  Maybe I could pick them back up.  Maybe I'll revisit it at some point, and do so, and make it better.  Applying band-aids to it, or... perhaps... I'll find cures! – ways to make it that much better of an essay.  For now, though, "done is good" (not the first place I saw that idea, but the first one I found that seems to explain it).  Done is good, so I'm putting this out there.  I can iterate if need-be.

I will, though, leave in a few only-very-slightly edited notes from my earlier draft, of things I wanted to include:

more from the Workaround page on wikipedia:

Typically they are considered brittle in that they will not respond well to further pressure from a system beyond the original design. In implementing a workaround it is important to flag the change so as to later implement a proper solution.

Placing pressure on a workaround may result in later system failures. For example, in computer programming workarounds are often used to address a problem or anti-pattern in a library, such as an incorrect return value. When the library is changed, the workaround may break the overall program functionality, effectively becoming an anti-pattern, since it may expect the older, wrong behaviour from the library.

Workarounds can also be a useful source of ideas for improvement of products or services.

Also worth looking at: Kluge and Convention over configuration.  I had a bunch I wanted to say about the latter... I guess in an edit or a follow-up post, maybe.

I also put aside another quote from Dan Ariely:

And it also turns out it would have been good to give me breaks in the middle to kind of recuperate from the pain, all of these would have been great things to do, and my nurses had no idea.

And wrote the following about it... which, I'm just going to leave here, no-longer edited (because Done Is Good, and I want this to be Done):

If we're dealing with pain day-in and day-out in our jobs, then of course we're taking breaks from it.  And surely that reduces our experience (or rather, memory) of the pain.

But here's the thing: There's still a whole lot of experience of pain!  And I, for one, believe that a great deal of that pain is totally unnecessary.  And that it's up to us to work on reducing it.  Because maybe a few of us have the problem of chronic pain (on YouTube).  Which, if you'll allow some stretching of the analogy, is something I think I've ended up suffering from, for one reason or another.

Anyway, taking a little break from relating the pain, I'd like to emphasize something else from Ariely's talk -- having to do with motivation.  Even if we take the stance that the pain I'm talking about is caused by people doing things wrong, we are of course under no obligation to consider that people are getting things wrong intentionally.  Leading in to the above quotes, Ariely says (emphasis mine):

Here were wonderful people, with good intentions, and plenty of experience, and never the less they were getting things wrong, predictably, all the time.

And while I'm sure that some of the pain comes from inexperienced people, or even experienced people that one might deem to fall short of the threshold of "wonderful" – and even, every once in a while, if there may in fact be some ill intentions – still, I suspect that most of the time, the intentions (at the very least) are good.  They're just "getting it wrong".  And so my hope with this essay is to impart some ideas on ways of doing things that just might help people (including, perhaps, yourself) to get things right.

The thing I most hope will be "gotten right" more often as a result of this essay is that more of you, more of the time, will fix problems as you find them, when the pain is fresh – thus (hopefully) preventing others from having to ever experience that pain at all.