Don't Bite the Flip Bozo
Jim McCarthy coined the term "Don't Flip the Bozo Bit" in his book the "Dynamics of Software Development". McCarthy meant everyone has something to contribute so before you think someone is a bozo (and by implication ignore them in perpetuity) hear them out with an open mind. Alan Cooper, considered the father of Visual Basic and who now runs Cooper Consulting coined the phrase "The Inmates are Running the Asylum" in a book of the same title. Cooper's work is creating things that real humans can use easily. Maybe this is an over simplification, but I have exchange a few emails with Mr. Cooper and that was what I took away from the exchange. Inmates and asylums refers to software and maybe all technical things being designed for left-brained, highly intelligent people that like to solve technical challenges. People who get a thrill out of figuring stuff out. I am one of those people. If you are reading blog then you are probably one of those people. Most people aren't like that, or so the premise goes.
Let me give you a for instance: I still the names of most of the registers in a CPU and what they do. I still occasionally flip individual bits and watch what the CPU is doing. For me that is fun. Remote controls, terrible. Every time I buy a new device I get a new remote. There are too many buttons, two many remotes, too many codes, and universal remotes seldom work correctly. I even have a Logitech Harmony 1100 in an attempt to integrate all of my devices in my entire house to one remote, but even this thing is complex. Yes, it does integrate pretty much all remote devices into one device. The way it works is you program all of your devices into it with your PC, all at once. Then, you pick task-based groups of devices. For example, "Watch DVD" might mean turn the TV, set to HDMI mode, turn the Blu-Ray player on, and the stereo and set it to DVD Input. The problem is that if it doesn't get something in the right state it can't figure it out. The Harmony device goes through every possible device with the equivalent of the "are you sure?" dialog for each device, and this process can be almost as painful as using three different remotes. (I still love the Harmony device, but it takes a lot of techy maneuvering to get it to work, some times.)
My understanding of Cooper's idea is that things are too complicated, not made easy enough to use, and they should be made easier, or at least there is a market for making them easier to use. In my opinion this is the miracle of Apple—the computers and the iPod. Apple's had a mouse but it had one button. My iPhone pretty much has a one button does it all interface too. With the iPhone if you don't know what to do pushing that one button front and center is usually not the wrong thing to do and often is the right thing to do. In some ways all end user products could take a page from Cooper's mental playbook. Be easier, help me more.
The challenge is where is the fine line in the sand? Who is an end user? Every product that has any market has a user. For example, I use Visual Studio. That makes me an end user of Visual Studio, but Visual Studio is not easy and hasn't gotten easier in years. One could spend the better part of a career and not probe the dark recesses of Visual Studio completely. So maybe an end user is the last user in the food chain. By that logic Visual Studio is a part of the process and an end user is the customers of the software you and I write with Visual Studio. Does that make it okay for Visual Studio to have an almost infinite number of facets and complexity? It is a tricky question.
Let's call think of software development as a life cycle. Microsoft creates an operating system and Visual Studio. They are a supplier and their products are not simple to use—not in any real sense. Developers are consumers of Microsoft products but we are producers and consumers. Consumers of custom software can be consumers and producers or just consumers. If you create a tool that is used to create something else then your consumer is also a producer and by implication maybe it is okay for your tool to be complicated too. What if, however, your customer is the final consumer, the dreaded end user? Well, then it seems like your tool has to be easy to use, user friendly, capable of performing complicated tasks but uncomplicated. Here is the rub. Everyone in the chain up to the final user has used and produced complicated software. What part of the food chain thus far has shown by example or exemplified easy to use software? How will you or I know simple or easy when we see it or be able to invent simple or easy without experiencing it?
Maybe the Inmates are Running the Asylum but part of being crazy is not knowing. If every experience involves complicated tools and complicated processes then crazy is taking the time to do something else, that something else being making things simple.
Software that programmers use is complex. Languages and design tools are complex. Is it really any wonder that creating more software is a jumbled complex mess when all we are surrounded by is complexity.Computer languages are complicated. Software development tools and design languages are complicated. Is it any wonder that building software is complcated and the results are often complicated for users to GROK too. Surrounded by complexity what part of the food chain lends itself to producing something simple.