Automatic tool tips need to die.

I just noticed a typo when re-reading my post (in preparation for sending it to a friend) about software pain, and went to go fix it.  And, in the spirit of that very essay, I'm now going to rant about the experience I had.

Because you see: the effort of doing the edit was impaired slightly by the fact that blogger decided it was time to tell me something about sharing on google+ or something.  I don't know, I didn't really read the thing, because I was trying to get something specific done.  Anyway, it was popping up a sort of "dialog box" kind of thing, over the editing field, being in my face about whatever new feature it was trying to tell me about.  And when I searched on the page for the typo, it seemed to go away for a moment (I guess when the page scrolled, and the CSS-positioning had to get adjusted by some javascript or something), but then it popped right back up.  Right over whatever text I was searching for, which... happened to exist in more places than one in the document (it wasn't a misspelled word, just the wrong word, so the string existed elsewhere legitimately).  So I couldn't tell if I was at the right place yet (let alone make the edit), because this window kept covering up exactly the thing on the screen that I was trying to look at.

I find this horribly non-user-friendly.

If you've got a new feature you want to make me aware of, send me an e-mail about it.  I might actually read it, at a time of my own choosing.

If it's something so dire that using the site can't be done without knowing about it, then don't let me even see the site.  Present me with a page and make me make a decision, or acknowledge that I've read something, or whatever it is you're trying to do.  This is annoying too, and is often over-used, but... still, it's better than the automatic pop-over thing, and if it's really both important and urgent, then it's the right answer.  If it's quadrant 1, don't let me do anything else until it's done.  But you're making something that, for me, is quadrant 4 into something that's quadrant 3, which gets in the way of me doing something I consider to be quadrant 2... and frankly, that pisses me off.

If you want to have tool tips for actual tools, where I actually have to hover my mouse over something to see it, that's totally fine with me.  (I'd like to have the option to turn them off, of course, but I find that in practice, I usually don't.)  And if you want to advertise some new feature or something, that you think I might really like to know about, then I'd even tolerate having a bit of screen real estate devoted to some sort of notice about that.  Make it dismissible, and I'll very likely take the time to read it and then dismiss it at some point when I have half a moment, so that I can get my screen real estate back.

But when you put something that for me is quadrant 4 directly in the way of me trying to get done my quadrant 2 work done, thus making it quadrant 3 (urgent, but not important), you're causing me some pain.  If you want to keep me as a customer[0], please stop doing that, lest I drop out.

Much as I dislike supporting Covey[1], I do like to try to stay in quadrant 2 of his urgency/importance matrix when I can.  Stop feeding me quadrant 3 stuff, please.

Oh yeah, and to the rest of the world: I ask you to stop putting up with annoyances like these.  if you'd like to understand why, please go read that article on software pain (linked up top).

---

[0] To some small degree, I specifically mean google and the blogger platform team.  Mostly, though, that was just the particular instance of a broader trend that I've noticed which caused me to write this post.

[1] For reasons I won't bother saying here, right now.

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.

I wish everyone put -Wall -Werror into CFLAGS in their Makefile(s)

Random geeky rant:

I wish everyone (especially people maintaining libraries for others to compile against) would use -Wall -Werror (and maybe even -pedantic and other such things) in their Makefiles for things. It's really quite simple, just find the line that looks like:

CFLAGS = -g # and/or whatever else

and add -Wall -Werror to the end of that, like:

CFLAGS = -g -Wall -Werror # and/or whatever else

Oh, and I've recently learned of another one, to enable "extra" warnings, and a nicer way to put them into your (GNU) Makefile:

CFLAGS += -Werror -Wall -Wextra

Get your compiler to force the issue of fixing your warnings, so someone else won't end up stuck with them. You know your code better than someone else will, so you'll be much better at finding the right fix to the warning.

I'd give extra bonus points to anyone adding these to default configurations (default option for gcc? Apple make these the default for Xcode, etc.). There might be downsides to that, but... oy. So many projects have so many warnings, many of which (though I'm sure not all) are likely bugs that could be fixed if people would warn about them.

[Note: this article was edited 2011-02-28 to add new content, and re-shape some of the existing content.]