Saturday, July 30, 2011

They Made Me Do It

Security is a favorite excuse; "We can't do that, because of security". This is usually at least sort of true, but it is rarely entirely true. I present another rant in the form of an extended metaphor.

Suppose somebody takes the dog to the vet, and comes home empty-handed. "I'm sorry honey, the vet said we had to have him put to sleep." There are a lot of ways the vet can feel about that statement, which is almost never absolutely true.

It could be that the vet said "I strongly recommend putting the dog to sleep; otherwise he will just be in pain until he dies." In that case, the vet is going to feel that it's pretty fair to say "the vet said we had to have him put to sleep".

It could be that the vet said "There is a treatment available, but it is expensive, time-consuming, and uncomfortable for the dog, and there is no guarantee it will work. There are people who undertake it, and there are people who have the dog put to sleep; those are both reasonable choices." The vet is likely to feel less happy; the vet offered choices, the dog owner picked one, they were both hard choices. It's true that the vet did not produce any non-fatal choices the owner liked, but still, the vet did not doom the dog.

It could be that the vet said "Oh, we can treat that. It'll cost $100 and you need to give the dog pills every day for a week," and the dog owner said "Oh, I don't want to do that; what happens if I just don't treat it?" and the vet said "Then you'll have to put the dog to sleep." The vet is likely to be upset at the characterization "the vet said we had to have him put to sleep". The vet offered a different choice which most people would accept.

It could finally be that the vet said "The problem here is that you are not being a responsible dog owner; if you let the dog run loose unsupervised and it bites people, we'll have to put the dog to sleep." The vet is likely to be outraged at the idea that this is the vet's fault.

A lot of "we can't do that because of security" is like that. "I'm sorry; you can't do that thing you want to for security reasons" might mean "it's not safe" or it might mean "the safe options are really expensive and onerous" or it might mean "the safe options are more expensive than I'm willing to pay for" or it might mean  "the safe options involve actual effort, and I'm not willing to do anything at all" or it might even mean "I don't want to but I don't like taking the blame." (I would like to think this never happens to dogs, but I am very much afraid that it does.)

Saturday, July 23, 2011

How Hard Can It Be?

Footnote: This is a revised version of a post with exactly the same point and the same opening from 2009. Also, it is very closely related to the standards problem, here explained by xkcd.

Of all the reasons that people get sucked into rewriting software, the one that drives me craziest goes like this: "Well, there are a bunch of versions out there, yes, but they all suck. So we decided to write our own. How hard can it be?"
Well, I dunno, it can be hard enough that a bunch of other people tried it, and their versions all suck. It's true, the world is full of mediocre programmers, but take a look at those versions. 
One commercial version might have been written by 2 bozos in a corner and then shamelessly exploited by a money-grabbing company trying to fill a vacuum. More than one? Longstanding products? Somebody who can do more than grunt was involved at some point. 
One open source version might have been written by a crackpot and released in a forlorn attempt at self-aggrandizement. More than 5? Some of which are longstanding projects with multiple contributors? Once again, a reasonable amount of brainpower has been unleashed here. 
If the result sucks, the problem is hard. And unless you have a brilliant insight they didn't have, your version is also going to suck. (If you do have such an insight, you do not ask "How hard can it be?" You ask "How come nobody else ever tried [fill in the blank]?" and let me warn you that this is not a rhetorical question, because sometimes there are very good reasons.)
Why do some problems -- time card systems, bug tracking systems, trouble ticket systems, monitoring software, to name some of my more frequent nemeses -- suck people into believing they cannot be hard when manifestly they are? In general, some combination of the following features:
  1. Every environment has some customization that is, in itself, relatively trivial, but is sufficiently environment-specific that it is hard to implement in a program meant for other environments. When you contemplate the programming difficult, you calculate the difficulty of adding that customization, not the problem as a whole, forgetting all the difficult problems that the existing system has already solved.
  2. Small and specific versions of the problem are easy to solve; scaling and customization are the hard parts. You can solve your organization's whole current problem easily and will not discover the lurking traps until later (the timecard programs works great until employees start moving between time zones, the bug tracking system works fine until a million bugs, the trouble ticket system works fine until the second group of people need to use it, the monitoring system deals with the network devices fine but stumbles when you need to manage systems).
  3. The underlying parts of the problem are relatively tractable, but putting a user interface onto it that  isn't disgusting and hard to use for large portions of the user base is difficult. (Do user interface designer design beautiful interfaces for things that then nobody can program the backend to adequately? Probably.) In this case, even if your program works right, the users will think it sucks. See, for instance, every time card system I have ever been forced to suffer through, most of which seemed quite competent at dealing with my more normal time card needs, after I had learned to perform the arcane rituals needed to actually enter the data. Nevertheless, once your program has made me cry, I do not care that it was just a few hundred UI issues, not a fundamental algorithmic flaw. 
If you actually have a novel insight into one of these problems, more power to you, please do build your new system (although I have to warn you that at best a significant minority of users will still hate it). If it just seems logical to you that there must be a better way, please do not unleash your version onto the universe until you figure out exactly what that better way is. 
And please resist the temptation to believe that it will be cheaper to build yours than to try to beat somebody else's into submission until it is bearable. It may be more personally rewarding, and that may be a perfectly good reason to do it. But it will almost certainly be just as expensive. 

Saturday, July 9, 2011

Programming Metaphors You Need, Part 1 of Birds

Some years ago, my mother was sick in bed, and the family cat, apparently feeling she needed perking up, went out and got the best present it could think of. It hunted vigorously for hours, and exercising all the smarts and power it could muster, it found the perfect thing, and brought it back to my ailing mother.
My mother, awoken from fever dreams to find a half-dead bird in her bed, was not appreciative. Actually, she was more horror-struck. There was shrieking. Cat and bird were both banished summarily.
My mother and the cat both sulked for days, furious at each other for the cruel way they were treated when each had behaved as well as one could possibly hope for.
I myself have had an eerily similar interaction with a programmer who proudly showed me a feature which he thought was incredibly useful, and which had also been very tricky to implement. He was outraged to discover that I did not adore it. In fact, my first response was to ask how to turn it off, out of fear that I would trip it accidentally. He felt that I was unappreciative, resistant to change, and failed to appreciate how life-changingly useful this feature would be. (Our disagreement was not improved by the fact that it was possible but not practical to disable.)
He did have at least one thing right; unlike the half-dead bird, it proved unobtrusive. In 10+ subsequent years of using software of the appropriate type, I have never once wanted this feature, and have often been in situations where it would have been dangerous, but I did successfully use his version for several years without accident.  I'm sure he continued to enjoy it, and his virtuousity, to no end. I just wish he hadn't given it to me.
Software is often full of dead bird features. It’s not valuable because it was difficult to implement, or because it makes developers happy; it’s only valuable if it makes the users happy. Save the dead birds for those who appreciate their excellence.

Edited to add:
It's not just programmers that come up with dead bird features, of course. For instance, the ultimate dead bird feature is almost certainly Clippy, the animated paper clip that used to offer to help you with your Microsoft Word documents. It was a masterpiece of technology, lovingly crafted, and beloved by its audience. But lots and lots of people found it not merely unattractive but actually repellent. There you were, working away, when AARGH! your eye was drawn to an animated paper clip, actively trying to distract you from your work in order to offer to help you do something you had no interest in.


I'm working on blogging more often and splitting out topics. This blog is for my more computer-related rantings (there's something about computers that inspires ranting). The kid stories are staying at OTOH and the art is at Naming Cats is Easy, Naming Art is Hard.