Lispian Random meanderings on whatever catches my fancy

Asylum Seekers

One book I constantly reference is Alan Cooper’s The Inmates Are Running the Asylum. It is an excellent book explaining the difference between what a techie sees are how software should function versus what a normal person sees and wishes software would do.

It all boils down to the difference of putting the onus on the developer to make the software as easy and intuitive as possible versus making the poor end-user jump through hoops to get anything accomplished. It’s the notion that whatever is done should be as easy as possible for the programmer to code as opposed to making sure the end-product is something that doesn’t aggravate, confuse, or otherwise enrage the end-user.

Cooper further states that software should just be “good enough”. This is a common refrain today, but a few years ago was rather heady stuff. I’ve long believed “good enough” would solve a lot of our troubles but most people in high-tech are perfectionists who spend an infinite amount of time honing their craft and their software to such an extent that it either never gets out or when it does get out is rather useless.

In this way Cooper is also proclaiming that Agile and similar RAD-like development methodologies are the way to go. Build something that accomplishes something useful and then get it out there. Then refine the solution incrementally, meeting the needs of users as they voice them. This is also the message you get from folks at 37signals, which they document in their book Rework. I’m planning on reviewing that book soon.

The point of this review is to actually comment on the fact that software is unnecessarily complex. That everything about software is unnecessarily complex. It’s as if all the lessons learned in the 60s and 70s, especially with Unix, have been forgotten. The attempt to make software simper to use, APIs simpler to call, etc. seems to have been lost in some kind of odd frenzy to make software complex for the sake of complexity — or to prove to the world that it’s hard. It’s all rather stupid. Software in and of itself is hard and complex. We don’t need to add complexity to it ourselves. That just makes it harder to get anything done. I look at languages like Java and wonder what in the world were the designers thinking? You can read an excellent lament about the state of programming by Rob Pike who has gone on to develop Go. Now, I’m not that fond of Go because I think it’s a throwback style language, but at least he’s voiced the lament. It’s all gotten to complex, too cumbersome, too slow, etc. It’s all stupidly complex. To the point that writing even the simplest of programmers in some of the “modern” languages takes so long it just frustrates old guys like me to the point I’d rather never program computers again!

And there’s no justifiable reason for any of this. Every aspect of development should focus on making things easier. And, no, I’m not talking about IDEs which I think just spawn complexity and obfuscate how things are done. They provide what appears to be an easier environment within which to code but I’ve come to think they actually only make lazy programmers who know more about cutting and pasting and less about true programming.

Thus Cooper talks about how bad things are and highlights this by showing programmers who go to extreme lengths to make something when a perfectly good enough solution is or was available.

I would argue this inability to comprehend “good enough” is what makes the early reviewers of the iPod condemn it because it only had a couple of buttons. There is this love of complexity that permeates many geeks/nerds/techies, so much so that they believe everyone is similar to themselves, interested in complexity and in love with the computer. Instead, Cooper aptly points out, most use computers as a tool. Making the use of that tool unnecessarily complex or over complicating development of extensions for a given tool or environment is simply silly.

Now, Cooper doesn’t always say do whatever makes the user do the least steps. He’s also aware that sometimes it’s just easier to have the user do something again, and provides an excellent example of a scanner he worked on. The “cool” solution would have been to write a lot of software to adjust for a misaligned page. The easy solution was to just have the user put it through the scanner again. I look over at my Fujitsu ScanSnap and realize that whoever designed that was thinking about the end user. It’s fast and if something screws up, well, it’s fast and it’s not a big deal to send it through again. I’ve been able to use the ScanSnap to rid myself of a lot of paper and I continue to use it to rid myself of paper and that’s a very good thing.

I do know that some of the reviews comment on Cooper’s ego or arrogant attitude. I didn’t find it that way at all. I found it to be a frustrated commentary. When he wonders why a program shows you menu items that you cannot use he states it because it makes no sense to show features that aren’t available. Or when he comments on providing users with more choice than they’re currently comfortable with, you quickly realize that a better way might well be to have levels of capability wherein the user slowly adds functionality as he or she gains confidence. This is similar to how many games operate. The games are simpler at the beginner levels, even supplying hand holding, but as the user ups the complexity the games become more complex and the user has to rely on their wits. Same should hold with software. When you’re just learning it, providing the ability to do something useful and therefore quickly see the value of the software is beneficial to both the vendor and the end-user. And as the user becomes more adept more features should become available.

I recommend anyone who works in software in any capacity to read this book. I’ve also recommended this book to end-users and executives so they better understand what they should be asking for, instead of defining requirements which read more like implementation details they can instead focus on what their true problem is and therefore are more likely to get a solution that resolves that problem.

Comments are closed.

September 2010
« Aug   Oct »