Innovation, Technology & Science

The Supermodel Software Theory

04.25.09 | 8 Comments

Cindy Crawford, The Supermodel Software Theory

Like many geeks, I like theories and laws. In fact, I have my own law: Harding’s Water Principle. Well, I’m advancing another theory that could become a law or principle, the Supermodel Software Theory.

I’ve spent the last 25 years of my life developing software. Some of it really bad, most of it simply average, and I’ve had the pleasure to work on very few extraordinary projects. I’ve been engaged in these projects as an architect, product manager, systems analyst, software developer, QA engineer, technical lead, manager, manager of managers, and executive. So I’ve seen the whole lifecycle, multiple times from multiple different perspectives.

Here’s what I’ve learned: Great software has three attributes; aesthetics, usability, and utility in a specific mixture which we’ll discuss in depth. Aesthetics are what you’d expect, is the software visually appealing and inviting. Usability covers how the human interacts with the software, is it easy to learn? To use? Do I want to use it? And utility covers the spectrum of functionality, does the software do what I need it to do to be useful?

Average software tends to be designed and developed by people who are content to benchmark. Go to any airline’s website, they all look the same, have the same features/functions, and generally behave in the same way. They have utility in common and largely compete in that arena (which is a good thing when you want to book a ticket, check flight status, request an upgrade, etc.) But, do you love to use the software? Do you want to go back? Or do you often dread fighting it to get done what you’ve set out to accomplish? What tends to be wrong is the over focus on the utility, features and functions everyone else has. Consequently there is an under investment/focus on aesthetics and usability and a lack of discipline in the selection of the features that truly matter to the user.

Example of ugly software

Bad software tends to be hugely unbalanced across aesthetics, usability, and utility. We can all think of great looking software that is useless, highly helpful software that is useless, and utilitarian software that is useless. Often, very popular software fits into these categories, for example, Dbase III (I’m dating myself by using this example) got the mix right, Dbase IV, messed it up royally. Consequently, Foxbase and then MS Access were able to take their lunch money.

Great software is like the rarest of supermodels; those people with incredible looks, a fantastic personality, and high learning agility. Why does this matter you might ask? For humans, if something looks good, it gets the benefit of the doubt (aesthetics.) That’s not enough to sustain interest, but is often enough to open the door. Now, if that supermodel has a great personality (usability) that goes along with their inherent good looks, you’re on to a winner. Why? Because ugly and mean are nearly impossible traits to fix. Finally, if we discover that our supermodel has some useful skills, but even more importantly, is willing and able to acquire new skills, we’re going to be very, very happy and we will attempt to form a long-term relationship with that person.

Stupid and ugly are hard to fix

It’s worth talking about learning agility. Like ugly and mean, stupid is nearly impossible to fix. Ignorance can be addressed. This learning agility – the ability to transform ignorance into knowlege – is an analog to the utility layer. How we do this is to focus on a small subset of things where we can excel. Over time, by doing this consistently, the base of knowledge (or utility of software, or feature breadth if you will) grows ever more complete and compelling. But the important part is to select one area where the software can be truly excellent. In the utility portion of software development, the industry at large has little discipline, we go overboard, trying to get every feature/function under the sun stuffed into the software. While that can be intellectually interesting, it’s not particularly helpful.

The theory is: Like a supermodel, it’s essential to have pretty, nice, basic and focused competence, and learning agility in software because people are predisposed to accept the possibility of improvement when they enjoy the product. The order is vital, because people are less tolerant of highly utilitarian software lacking looks and personality (we may hope we’re better than that, but we’re not. Remember, ugly, mean, and stupid are forever. Ignorance can be cured.)

Jessica Biel, build a supermodel caliber software package

So, using the theory, the recipe for building great software is pretty straight forward. Design a compelling user interface first which ideally contains the core feature where your software will be truly excellent. Resist the urge to benchmark. Test your concept early and often with your users and adjust as quickly as possible. It’s better to be pretty, with a good personality, and only truly excellent across a narrow area to start. Once in the market, identify the next most vital utility in a narrow band, get that right and release it. Rinse and repeat as necessary. Now, does this guarantee extraordinary software? No, it doesn’t. But if this process is followed, the chance that your software will be great increases dramatically.

So, the next time you or your company plan to undertake a software project, dust off this theory and try it. Remember, the choice is yours. Escape the tyranny of benchmarking, resist the urge to load down the project with hundreds of features, and find a nice, attractive, project with high learning agility to bring home to meet the family. You’ll be glad you did…