Mansions of cards: Osinki, CDOs, and the role of software

The aim of software is, in a sense, to create an alternative reality. After all, when you use your cell phone, you simply want to push the fewest buttons possible and call, text, purchase, listen, download, e-mail, or browse. The power we all hold in our hands is shocking, yet it’s controlled by a few swipes of a finger. The drive to simplify the user’s contact with the machine has an inherent side effect of disguising the complexity of a given task. Over time, the users of any software are inured to the intricate nature of what they are doing. Also, as the software does more of the “thinking,” the user does less.

From My Manhattan Project: How I helped build the bomb that blew up Wall Street. Highly recommended; the article touches on the ethics of software development, user interface design, complexity, and the classic question of the degree to which a creator may be held responsible for the acts of his or her creation.

It is not Osinski’s fault that his software makes it very easy to perform some otherwise rather difficult algorithms; that is, after all, much of what a computer does. But it does make me wonder that he agreed to work on it understanding full well that the technique was built on entire mansions of cards, and it serves as an ample reminder that our moral compasses are so often attuned only to the values of those around us.

But what, then, is appropriate user design? Should business software be ugly, difficult to use? Should it, like a disassembled watch, expose its innards for all the world to poke and prod at? Must an operation that you suspect your user does not rightly understand always come with a warning label: “Don’t touch unless you really, truly know what you’re doing”? Isn’t that just condescending to your users?

Like everyone else, I’ve used my share of software that I absolutely loathed; software that made simple tasks hard and hard tasks devilishly impossible, their user experience an afterthought, a victim of shrinking budgets and small visions. If there’s anything I’d like to see improved in what you might term the ecosystem of enterprise software, it’s the fact that so much of it is, from a human point of view, really wretched. If you must make people use the stuff, don’t make them dread the experience.

But am I wrong? Should an ugly veneer serve as a reflection of inner ugliness, or of my own lack of understanding? I don’t know how many kinds of Photoshop filters work; should I as their user ask the designers of Photoshop for a poor interface design, so as to force me to pay a psychic penalty for my ignorance?

Of course not. As developers, our eagerness to please our clients and stakeholders is, after all, only human, and anyway, software projects do not have a great track record of success when it comes to satisfying the demands of their procurers. Some projects are wise and some are not; Osinki labored foolishly, although surely if he had not taken up the call some other equally talented developer would have. Agile development, I think, provides us with the tools to build software more rapidly and closer to spec than ever before; so let us then pick our projects wisely.

Why do type checks in dynamic code smell?

Code comments, alias_method_chain, extensions, and the importance of expressing intent