2012-08-11

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.

2012-04-15

Hygiene and smoking...

New rule:

Any Gelato establishment with a sign that says:

"Due to hygienic reasons, it is not possible for us to let our customers taste the ice cream. Thank you for your understanding. The staff"

Well, such a place ought also to ban smoking, don't you think? I don't care if they do have a full bar, also. (Wait, why does a Gelato place have a full bar? And why is that sign only in English? Well, I'm guessing I can guess at the latter answer - only Americans expect the option, perhaps. But still...)

Rauchfreizone

To all restaurants and the like who exist within a locality which has not banned smoking within such establishment (and to the localities: please do), yet which have a smoke free area:

First off, thank you for at least going part way on being smoke free.

Would you like a tip on making it even better, though? Since this is a mostly of one-way form of communication, I'll just hope you answered yes to that, and give you this suggestion:

If you make sure that all the critical sections of your establishment (and especially: entrance, cashier, and WC) are in the smoke-free zone, you'll surely make your non-smoking customers much happier, while costing little to your smoking customers.

Thanks.

- David, in Wien.

Global transit passes

Imagine putting money on a card that you could then use at any transit system anywhere on the globe. Different fares would be deducted, depending on the system - and fares in different currencies would somehow have to be figured out. Perhaps disabled and age-based (youth, senior) fare flags could be applied on the card - and either just transfer that data, trusting any authority, or have the authority of one system at least give you a temporary use on a new system until such time as one could b re-certified locally.

And then, too, perhaps passes would automatically be granted on an as-useful basis: Ride once, pay one-ride fare. Ride again, a few hours later, pay again. Ride a third time in the day, pay a half fair (or whatever it happens to be) to upgrade you to unlimited-rides-for-one-day rate. Ride a couple times the next day, auto-upgrade to two-day unlimited. And then 7-day. And then monthly. And then yearly. Or not... Always paying the lowest possible fare for what you're actually using.

And maybe, just maybe, if you auto-upgrade in, say, Los Angeles on a Wednesday to a 7-day pass that started on Monday, and then you're in Berlin on Thursday, you'd pay at most the delta in weekly fares (as adjusted for US$ to € conversion) to get unlimited rides through Sunday.

Or maybe just have the TAP cards they use in LA actually work on all the buses in LA. I just had to pay a cash fare on a "big blue bus" #3 to the airport after using my TAP card just fine to board a Metro 33 to get to that 3. Sigh.

2012-01-04

On Secular Tithing

Wow... How have I not talked about this before?

Let's start with a story, though:

Once upon a time, there was a guy who volunteered some of his time as a mentor at an organization called Youth In Focus.  Youth In Focus, or YIF, as its regulars often call it, is an organization that teaches photography to underprivileged youth in the Seattle area -- to help keep them off the streets, to give them something fun to do, to teach them a marketable trade, and, perhaps most importantly, to help build their self esteem.

Well, one day, this guy found out that because one of the regular donors to YIF had not done their annual donation in a particular year, YIF was going to have to cut half of its program for several quarters.  They'd run 3 classes, instead of 6.  Oy!  This guy was not thrilled with this idea.  So he asked the Executive Director one day: What would it take, financially, to *not* have to run the program at only half capacity? The answer: $10,000.  At first, he tried to get other mentors excited about doing some fundraising with their friends and contacts...  But, for reasons we won't get into in this post, the guy was unsuccessful in getting anywhere close to $10,000 with this tactic.  And that Spring quarter, they ran at half capacity.  For summer, though, they were able to run full steam.  Good thing.  Fall, though, was still on the chopping block.  And this was not OK with this guy -- it was putting him out of a job as a mentor, and putting a whole lot of kids out of having what he perceived as a very useful class.

But what could he do?  He hadn't managed to get enough traction with the other mentors to make the difference.  He wasn't working at the time, and couldn't just donate the funds himself... but...  He did have some money around, and he had an idea for something he could do.  And he did it: He gave YIF a directed matching donation of $5,000, with the expectation that YIF would use that as incentive to raise an additional $5,000, and run the program at full capacity.  And they did raise that extra money, and they did run the program.

But wait, he's out of work, and he has $5,000 to kick around?  How?  Why?

Well, here's the thing.  This guy had started something back when he was working that was the thing that made this all possible.  He was doing a non-religious form of tithing.  Any time he got a paycheck, he would take 10% of the gross amount, and put it in a separate bank account, set up especially for the purpose.  Then, sometimes, he could give some of that money to some philanthropic cause.  Youth In Focus was the lucky recipient of $5,000 from this account.

This story is true.  And, as you've no doubt guessed, that guy was me.  And I want more people to tithe in a secular way.  I'm not alone... for example, the Atheist Activist website describes secular tithing as a way to "offer material support - our money and our time - to organizations that do good by advancing the values that atheists hold dear".  Yeah, sounds about right.  I just want more people to be doing it.

So, in hopes of promoting the idea further, I've created a facebook group.  Not that facebook is the answer, but it was an easy way to get things started.  I call it the World Secular Tithing Society, and I hope you might join.  The idea is to spread this idea, and encourage others to tithe -- to their own accounts, and/or maybe at some point to some non-profit that's specifically set up for the purpose of managing the collection of funds from secular tithers and getting it to charitable organizations that serve secular needs in secular ways.  Perhaps if some of you join the group, you'd be willing to help me create that non-profit, and make this thing a reality?  Or just join... give my posts a "like" now and then, and maybe tell a friend or two.  Or twelve.  Or 10% of your friends.  That might be fitting.

Anyway, one way or another, won't you help out?  Join me in doing this, whether or not you join my group?  I believe the world would be a better place if more of us did secular tithing.  I hope you'll agree.  Thank you for reading.

Addendum: Shortly after writing this post, I got to a message in my inbox that mentioned the Sustainable Path Foundation... which seems to be precisely the sort of thing I'm talking about: a secular organization that pools funding together to solve problems in the world.  Isn't synchronicity fun?