DRY Legislation (Don't Repeat Yourself)

I don't know much about the United States Code, really. One thing I do know, or have at least heard, repeatedly, is that it's immense. Individual bills sometimes come in at thousands of pages, and go completely unread by a large percentage of the legislators who vote on them.

This is the story, anyway. I'm presuming it's accurate.

And it strikes me, in thinking about this, that probably a large percentage of all those words involve some sort of standard boilerplate-like language that shows up again and again - either across bills, or within a bill. Maybe that's not at all the case, I don't know. But knowing what I know about how I've seen things done elsewhere, I'm inclined to guess that it's likely. It's certainly a common thing in a lot of software I've seen (and some I've written), to express the same things over and over again.

And in software, it's often a horrible way to go about things. And I suspect the same to be true in the world of legislation.

It's understandable, mind you... One time you want to say "one time you want to say", and another time you want to say "another time you want to say". They're not identical statements. Yet there's a whole lot of repetition there.

There's been a movement in the software world to keep code "DRY"... An acronym for "Don't Repeat Yourself". In computer code, this is arguably a lot easier than in English. You have functions, and variables, and a readership who knows how to deal with these sorts of things. So you can do something like (in some arbitrary pseudo-code English):

1. Let "tywts" mean "time you want to say".
2. One tywts, "one tywts", another tywts, "another tywts".

There's arguably still repetition there, of course. And in a real code environment, there'd be ways to reduce it further. Still, if you decided you wanted to change things to be "one time you wished you had said", you only have to change it in one place (never mind that the acronym is now obsolete in its lettering; you could fix that, too, but you don't have to). This is one of the major wins with DRY code. And I suspect there are a lot of places in legislation where we could do something similar. After all, the readership of legislation is presumed to be sophisticated, too.

So make a library of specific definitions - within the body of law, overall, and within specific laws, as needed. An then express ideas in succinct, if slightly cryptic to the lay reader, ways. I think that might be better. At the very least, I think it's worth thinking about.

And maybe some day we'll set aside 5% of congress's time for a decade or three to "DRY off" the existing laws.


More atheists in Congress... (write your reps!)

Apparently, there are some 28 atheists in Congress, only one of which is open about their atheist views.

Personally, through a wide variety of inputs (perhaps I've written about these?  And/or perhaps I will (more) in the future), I've come to the conclusion that only an open atheist is really in the best of positions to be a legislator.

As such, I've just written to Jim McDermott, my representative in the House, the following message (which says a little more about why I hold this position):

Dear Congressperson McDermott, 
I've been voting for you for the last several years, and I've seen you speak a few times, and generally I must say: I like what you're doing. Which means I'm inclined to want to see you continue to represent me in congress. 
However, there's a point where I'd like to be more represented, where I'm less sure about how well you represent me: 
I'm a staunch believer in evidence and reason for deciding truth, and as such, my reason and the best evidence I've been able to find so far leads me to being a fairly strong believer in the absence of a personal god, or really pretty much any deity, though one does have to carefully define ones terms before one can reasonably have the conversation. 
At any rate, I've further come to the belief that I strongly want those who represent me in government to have a similar position, and take it openly.  For I feel there are basically two main possibilities for someone (and particular, someone in congress) who identifies as a religious believer (and specifically a believer in a personal god - which may or may not be you?  I'll get back to that): 
1. That this someone either has not looked at, or is ignoring (for whatever reason or reasons), the evidence for non-theistic explanations of the way the world works, and evidence against the existence of a personal god; or
2. Someone who has examined the evidence, and doesn't believe in a personal god, but for whatever reason or reasons (and there are some arguably good ones; cf. a talk on this topic by Daniel Dennett[1]), has chosen to lie about it. 
In the former case, I'd worry about this person's ability to use evidence and reason to make good decisions about how to interact with the world, especially when making policy decisions as my representative in congress. 
In the latter case, I'd worry about the mental hoops this person has to jump through in order to lie to me and others, and about what else they might be able and willing to lie about in the course of their service. 
In either case, I'd much prefer a representative who had examined the evidence, concluded that a personal god did not exist, and was then able and willing to openly admit to this. 
Now, according to wikipedia, you're a member of the Episcopal church.  According to the same page, you also led a recitation of the pledge of allegiance, rightly (in my opinion) omitting the added words "under God".  I've done a little bit of searching, and don't immediately find more information on your actual beliefs in this area... 
So I ask you: 
Are you, privately, an atheist? 
If so, I simply ask you to consider "coming out", and making your atheism public. 
If not, I ask you to consider the evidence (as presented, e.g., by Victor J. Stenger[2]) that exists against the hypothesis that a god exists, and if you find it convincing, to then consider my "if so" statement again. 
Either way, if you're willing to speak candidly (either in direct correspondence with me, or publicly) about your beliefs, or if you have in the past and can point me at some record of such, I would greatly appreciate hearing your views.  The one thing I will ask you NOT to do is to tell me that you're a believer if in fact, deep inside, you are not.  If you will keep your non-belief hidden, I can respect that (to some degree).  If you truly do believe, well, I'd again ask you to look more closely at the evidence, and/or I'd be happy to have a conversation with you about it, should you wish to do so.  If you disbelieve and explicitly say otherwise, though, then I have real trouble with that.  So I ask you not to do so. 
With respect and continued support, 
- David Lindes, a Seattle constituent.

[1] http://www.youtube.com/watch?v=BvJZQwy9dvE 
[2] http://en.wikipedia.org/wiki/God:_The_Failed_Hypothesis

Now, I ask you to do something similar.  Write it in your own words, to your own representatives (whether in the senate or the house, or ideally both; perhaps I'll follow up with Murray and Cantwell, as well).  If you'd like to link to this blog post, feel free, but mostly, just write, OK?

Thank you for reading.


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)

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).


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.


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...)


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.


- 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.