Friday, February 02, 2007

Five Myths of Software Developer Behavior

I’ve been known to read a book or two on management or marketing now and then. I know it’s a personality flaw on my part. I should be reading books on agile development processes or the latest new language like Ruby on Rails. But the fact is most high technologies have a half-life of about five years. When you get to be a certain age, and have survived a thirty-year career in high tech, you have seen so many technologies come and go it’s hard to get excited about something that in the long view seems like just another fad. Plus, you figure maybe it’s a good idea to practice just-in-time learning instead of expending bandwidth with stuff that you might not live long enough to use. Time is short, and you want to make the most of what you have left.

Even while reading a book on marketing, it is hard not to see it through a lens polished by decades of technical experience. And so it is that when I read Paul Smethers’ and Alastair France’s book Five Myths of Consumer Behavior: Create Technology Products Consumers Will Love, I chose to see it not as a book on how to design and market consumer-friendly products, but as a book on API design, and to see the consumers described in the book as other software developers using my code.

Is that sick, or what?

I’m sure if I specialized in user-interface design, such as GUIs or web pages, this short book would have even more resonance, since it talks specifically about the design of human interfaces for cell phones and web pages, based on work by the authors. But I found much of value just from my own experience developing real-time and embedded software for use by other developers.

Myth 1: Consumers behave the same in all markets

Five Myths describes the Consumer Adoption S-Curve, which is a sigmoid curve passing through the phases stalled adoption, to rapid adoption, to mass adoption over time. The first consumers who use your product will do so because they are curious, seek innovation, or have a problem they think your product can solve. As we will see later, only a fraction of those initial users become repeat users, only a fraction of those become regular users, and only a fraction of those become power users who may come to know more about using your product than its developers. If the barriers to entry to using your product are too high, you will weed all of your users out at the first stage, and your product will become stalled in the first (low) part of the sigmoid curve. The key to wide spread adoption is lowering the barriers to entry. Barriers to entry include usability, performance, and a product value that is hard to find.

I'm sure many readers have recognized this as being very similar to the cumulative Innovation Adoption Curve described by Everett Rogers in his book Diffusion of Innovations. Rogers separates his sigmoid curve into the phases innovators, early adopters, early majority, late majority, and laggards. While Smethers and France concentrate on talking about mass-market consumer products like web pages and cell phones, Rogers talks about how innovations ranging from new agricultural technology to rap music spread through a culture. The similarity of these two concepts suggests to me that both books are talking about the same thing, and that it is something fundamental.

Five Myths offers examples where consumers in different markets, for example Europe versus Japan, behave very differently in terms of what they find interesting or acceptable, making the same product or feature move through the sigmoid curve much more quickly in one market than in another. Success in Japan does not guarantee success in Europe when marketing the same product or feature.

A good example of this is to compare developers of enterprise software to those of embedded software. The success of Java in the enterprise was possible because that domain’s developers found the overhead of the JVM and its garbage collector vastly out weighed by its many advantages. Embedded developers just smiled and shook their heads. Historically this was also true about C++, and lately with its more exotic features like generic programming.

I have argued in recent articles that it is time for Java (“If Java is the new COBOL, is C++ the new assembly?”) and generic programming (“Generic Embedded Programming Using Templates”) to take their place on the embedded developer’s tool belt. But it is wise to remember that as technologies become mainstream, they filter though problem domains ranging from innovative to conservative, just as Five Myths describes.

Want to get a clue what embedded developers will be doing and using a few years from now? Look at what enterprise developers are doing and using today.

Myth 2: The more consumers see it, the more successful it will be

The biggest marketing effort in the world can’t make up for an ugly product. The secret isn’t attracting users. It’s keeping users. Marketing might get potential users to become initial users, but they won’t stick with an ugly product to become regular users. Products can be ugly (my term, Five Myths would probably say "unattractive") for lots of reason, like poor performance, poor usability, or value that is too hard to find.

Five Myths has a pretty interesting discussion on how products abandon their core consumers. Marketing managers insist on adding more and more features in an effort to broaden the product’s appeal. It evolves over time to the point where much of its installed user base can no longer find value in the product.

(A good metaphor for this effect can be found in popular entertainment. I was a fan of the television series Twin Peaks until I figured out that David Lynch was just making it all up as he went along and there was no hidden context. The series was cancelled shortly afterwards. The X Files came perilously close to this with its meandering mythology based on a government/extraterrestrial conspiracy. But it sustained enough great episodes that it remained worth watching. And of course there was the UNblonde character.)

I remember installing one of the popular Linux distributions, Ubuntu, on one of Digital Aggregates’ servers, only to discover that it did not include a C compiler. Apparently the folks that packaged this particular Ubuntu, which is marketed as “Linux for human beings”, was not marketing it to developers. (From this we can infer that developers are not human beings, something my spousal unit has wondered aloud about from time to time.) It was easy enough to download the GNU package and installed it, but it was definitely a WTF moment for Mr. Overclock.

While I know folks that are successfully using Linux as their desktops (and I still run it experimentally on an old laptop), all of those folks are hard core technologists, definitely not part of the mainstream. My laptop runs Windows, not because I am a Microsoft fan, but because I simply don’t have the time (see first paragraph) to figure out how to do with Linux things that are relatively simple with the applications available for Windows. And before you start commenting on how Mac OS is UNIX-based, recall that it is not Linux-based (and you will have to pry the Powerbook running Mac OS X from my non-technologist spousal unit’s cold dead fingers).

I have seen the same happen to products in the embedded tool chain, such as real-time operating systems. Victims of their own success, they become so feature-rich that one of two things happens. They can no longer be used by their core constituency for their traditionally memory-constrained applications, or they require so much memory that alternatives that were formerly unthinkable, like Linux, suddenly become competitive.

While I can appreciate the marketers trying to broaden the appeal of a product successful in narrow market segment, this can be the death knell if the product loses sight of its core value, the problem it was originally trying to solve.

Myth 3: If I’ll use it, my users will

On one hand, the points that Five Myths makes seem almost too simple and obvious. On the other, they are contrary to many truths that my technologist brain holds to be self-evident. This is one of the points of the book: engineers are power users of their own products, and are therefore the least qualified to have an opinion on how to make a product attractive to a new user.

It is difficult, for me anyway, to try to view the APIs that I design from the point of view of someone approaching it for the first time. Yet that is exactly what I think you need to do: try to see it with new eyes. And be willing, eager even, to evolve it once you have some real developers using it and getting their feedback. Don’t be afraid to say “this was a stupid idea” and move on. If it really is a stupid idea, why would you want to keep it around? Maybe it’s just stupid in the current context. So keep it in your hip pocket for when you find a context in which it is a brilliant idea. But don’t force it on your customers.

I’ve become skeptical over the years of design reviews that do not incorporate some kind of actual use of the API as part of its evaluation. The most useful technique I have found that did not require running code was to at least code up the interfaces or header files defining the API, with no executable code behind them, and code up some example programs using them to see how it feels. Even without any executable code, I was surprised how many problems this technique shook out. Plus, if you comment the interfaces with JavaDoc or Doxygen, the result is the beginnings of a usable (and current) design document.

Of course this sounds an awful lot like some of the precepts of agile development, like working closely with the customer, and test driven development, and so it is. I find a lot of API issues while writing the unit tests. These problems range from “this isn’t pretty”, to “this is awkward” to “this doesn’t work at all”.

Myth 4: Consumers will find a product’s value

Five Myths says you have to make your product's value obvious right up front, and make it easy for consumers to find it. Using web pages for mobile devices as an example, you lose customers with every single mouse click and menu drop-down they have to go through to use the feature they really want to use. With every step consumers have to take, a proportion of them give up and spend their attention budget elsewhere. Place enough barriers to entry in their way, and they give up, weeded out before they ever figured how why they should care.

So it is with APIs. On a Java project I remember comparing JAX-B with XMLBeans as tools to convert between Java objects and XML. I didn’t particularly like either one of them, but for sure the one I liked the least was the one that seemed to take more work to get something usable.

Five Myths is the latest among books I’ve been reading that push an evidence-based approach: evidence-based medicine, evidence-based management, and now evidence-based marketing. It’s easy to be lulled into thinking that evidence-based marketing is the norm, what with all the talk about focus groups and consumer surveys. But Five Myths tells us about how most such approaches are deeply flawed, and frequently only serve to reinforce mistakenly held beliefs by the product developers and their market managers.

Five Myths suggests an approach I recall reading as having been used by the early Intuit developers: give your product to real customers, follow them home, and watch them while they use it. The most useful feedback I’ve ever gotten on how difficult most systems are to use is when I watched over the shoulder of an actual customer as they tried to use it. The second most useful is when I tried to do the same while an irate customer was standing over my shoulder. This is why I strongly recommend that developers interact directly with customers. And not just in the customer briefing center either, which is a restrained and carefully controlled environment, but at the customer site, where the products are being used. I guarantee that it will be a valuable learning experience, albeit perhaps a painful one for all involved. (You might even make a friend or two.)

I’ve come to think of this as evidence-based design. Design based on facts and measurements, not on what you think is right. Agile proponents will recognize this as a form of don’t build it until you need it and incorporate the customer into the development process.

Myth 5: Consumers want more features

Consumers do not want more features. More features only confuse them and serve to hide the value (if any) in your product. When it comes to features, less is more. It is better to have a few (maybe as few as one) key features that work well, than a lot of features that all work marginally. This contrasts sharply with the boil the ocean approach of many modern software products.

Five Myths classifies features as to their attractiveness, their stickiness, and their usage. Attraction is the ability of the feature to attract consumers to use it. Stickiness is the ability of the feature to attract repeat users. Usage is the ability of the feature to engage a customer over a period of time. The most successful features are those that have high measures of all three metrics. But a feature that is just attractive, like a built-in MP3 player, may encourage potential users to become initial users, where they discover a sticky feature, like text messaging, that keeps them coming back. A high usage feature, like cellular phone calls billed by the minute, increases revenue.

This plea for simplicity describes well the problems I have with many software tools, frameworks, and APIs. They are just too damn complicated. It takes too long to come up to speed on them (see first paragraph) and to ferret out the best practices for using them, when all I really want to do is make my dates, ship a product, and book revenue. (All good things come from booking revenue.)

And many software products seem to be designed by a committee, having every single imaginable bell or whistle, with a cumbersome API that tries to be all things to all people. The POSIX Threads API comes to mind. Of course, like many public standards, it was designed by a committee, and does try to be all things to all people. It is no accident that the original, simple UNIX API was the product of just a couple of guys sitting around in the lab. Popular new tools, like Ruby on Rails, are frequently the product of just one or two people trying to address their own issues and coming up with a particularly effective solution.

My own experience has caused me to re-think how I design APIs for the software that I write, and Five Myths just reinforces it. In particular it has changed how I design something as mundane as constructors. In recent work in both the Desperado C++ library and the Buckaroo Java library, I have started putting only the absolutely essential arguments in the constructors, and setting all other options via dependency injection using settors which return an object reference.

For example, Buckaroo features “Chip’s Instant Managed Beans, classes which vastly simplify exposing useful information as MBeans to remote JMX browsers like JConsole. (For those of you in the C++ world, this is akin to exposing MIBs to remote SNMP browsers, which can be a very good thing indeed for system monitoring and field troubleshooting.) The constructor of the Buckaroo Counters class takes one mandatory argument, an enumeration, creates an array of counters for use by the application which are indexed by that enumeration, and exposes that array as a Dynamic MBean via JMX. It makes exposing debugging counters and even simple controls absolutely trivial.

Of course, there are some optional parameters for this capability, like the name of the managed bean, the location of the mbean server, a logger to use for error messages, and a callback that tells you when a counter has been changed remotely. But there are usable defaults for all that stuff. Instead of cluttering up the class with a bunch of polymorphic constructors, Counters has settors for those options. And since each settor returns a reference to the Counters object, you can write your application code as simply as this


enum Fault {
FAULT_INVALID_CONTEXT,
FAULT_OUT_OF_SPEC,
FAULT_INVALID_CHECKSUM,
FAULT_ SEQUENCE_NUMBER
};
Counters fault = new Counters(Fault.class);


or as complex as this


enum Fault {
FAULT_INVALID_CONTEXT,
FAULT_OUT_OF_SPEC,
FAULT_INVALID_CHECKSUM,
FAULT_ SEQUENCE_NUMBER
};
Counters fault = new Counters(Fault.class)
.setCallBack(myCallBack)
.setMBeanServer(myMBeanServer)
.setMBeanName(myMBeanName)
.setLogger(myLogger);


I know this sounds like a mundane example, but I think that not only does this simple constructor design lowers the cognitive cost of entry for using this class, the fact that you don’t really have to know what an MBean server or an MBean name is in order to make effective use of it makes the value more obvious.

This isn’t a new pattern, and I certainly didn’t invent it. But I’ve recently warmed to it, and Five Myths just convinces me that this is the right way to go. Five Myths preaches simple usage, and if you absolutely must have options for the power user, hide them and provide usable defaults.

The Rapid Consumer Adoption Process

Five Myths defines the Rapid Consumer Adoption Process. It goes like this: Design Product, Implement Design, then iterate in the cycle Deploy Product, Analyze Product, Improve Product, until golden, brown and delicious. Developers will recognize this as just a form of iterative development. But this cyclic process is more controversial than you might think, and getting more so all the time.

As competition gets worse, budgets get tight, and companies are under more pressure to improving the bottom line while shortening the time to market, the fact that all product development is fractally iterative sometimes get lost. I remember ten years ago working on one product for as many as six release cycles, or about three years. In the past few years, the norm is more like two or even one release cycle before I’m pulled off and put on the next crash priority project.

This is not good. It’s not that products were shipped too soon, but that after they were shipped there was no budget to keep developers around to improve the product. I felt like I was shipping nothing but prototypes. Customers felt it too: many complaints were heard about slippage in quality. But the first release of those later products weren’t any worse than the earlier ones. In fact, thanks to improved tools and better processes like test driven development, they were often better. But they never got much better than that first release, and it was really this lack of maturing, I think, that the customers were complaining about.

Every time I complain about quality, I feel especially old and cranky. I remember when I had to hike three miles to the computer center, carrying a box of punch cards, through a foot of snow, uphill both ways. The fact is programming languages, development tool chains, and processes have vastly improved since I started my career in the 1970s. There is no way I would want to go back. But Five Myths is just another voice telling me there is still plenty of room to move forward.

Sources

Paul Allen Smethers, Alastair France, Five Myths of Consumer Behavior: Create Technology Products Consumers Will Love, ConsumerEase Publishing, 2007

Everett Rogers, Diffusion of Innovations, Simon & Schuster, 1962

Chip Overclock, “Generic Embedded Programming Using Templates”, January 2007

Chip Overclock, “If Java is the new COBOL, is C++ the new assembly?”, January 2007

Chip Overclock, “Uncle Chip's Instant Managed Beans”, December 2006

Buckaroo, Digital Aggregates Corp., 2007

Desperado, Digital Aggregates Corp., 2007

4 comments:

demian said...

I know it's a minor point in your post but I don't fault Ubuntu for not shipping GCC with their distro. I have no need to have GCC on my box. I write code in Python, Java, Groovy a little Ruby. And I haven't done the tar -xvf, make config, sudo make install dance to install new software on a Linux box for years.

Even still sudo apt-get install gcc isn't a difficult thing to do if you want a C compiler on your box. I like their approach of making decisions about what you probably need and just including that. It's insanely easy to install anything you want.

mcjoe said...

While I agree that Myth 5 seems to make sense, I'm not sure I can completely buy into it based on empirical evidence, in particularly Micro$oft Word. I am not sure a more bloated piece of software exists on the face of the planet!

Products with fewer features and more simple user interfaces have entered the market over the years, only to be trounced by the product with all the features.

I think I would restate this myth as "Users will take Advantage of Every Feature You Provide". We will want the features, because this is America, where more means better! But we are also lazy, so we won't figure out how to use these features unless they are drop dead easy. Which feeds back a bit to Myths 3 and 4.

Chip Overclock said...

Paul Smethers, co-author of FIVE MYTHS OF CONSUMER BEHAVIOR, had this to say about my blog article, and kindly gave his permission for me to post it:

I’m really excited to see the book have such an impact on you as to cause such a long dialog about how to apply it to API development. Ali and I both began our careers as developers, and still dabble in code as we solve customer problems in the field—you only barely went over my head, and probably landed right in the middle of Ali’s brain, which is more technical.

On reading your posting, I had some comments that may help clarify our message from the book:

In Myth 3, “If I’ll use it, my users will,” we never intended to say that you don’t have to use your own products—you should (even if you are a power user). In fact, it is required that you use your own product if you fall within the scope of the product’s intended market segment. But the real point in this chapter was to remind product designers that they shouldn’t consider the product or a feature as “complete” or “consumer ready” just because they use it. It may still need more work to meet the rest of your customers’ needs. Your customers don’t have the knowledge and drive you have for your products (which is why product designers are usually classified as a power users).

I love how you summarize the concepts of Myth 4 into evidence-based design. Although I’ve not used the term before, you nail exactly where we had to go in our careers as we transitioned from usability tests and focus groups (and whining to management teams to listen to the results) into data analysis to confirm or deny what we saw elsewhere (and finding the management teams listening finally).

Finally, I totally relate to your last paragraph, as I too find myself grumbling about the quality of both the software and new feature decisions in new updates. Every time I get a new update from Symantec, or now I worry about Microsoft Vista, I find that the focus is on new features I don’t care about (like Vista replacing menus with icons only). The things that I love and use every day in these products usually gets the least amount of attention in new releases. For example, I actually use Microsoft Windows to view my documents in folder windows I place on different areas of my desktop. Yet once a week or so, all of my window sizes and positions are lost and I have to painstakingly move each window back to the place I want it (and update the display options I prefer, like view by details showing only the size). Considering that Windows represents billions of dollars of revenue for Microsoft, wouldn’t you think it could remember where I placed and sized a window for more than a week? I can’t wait to see if Vista fails this basic test as well. After all, Windows has been around for 12 years since Windows 95. Maybe it is time to fix the main feature…the “windows.”

Paul Smethers
ConsumerEase
http://www.5myths.com

Chip Overclock said...

Alastair France, the other co-author of FIVE MYTHS OF CONSUMER BEHAVIOR, had this to say about my blog article, and also kindly gave his permission for me to post it:

I also enjoyed the analogy of it being barely over Paul's head and smack in the middle of mine (neither of us is short - but barely over Paul's head would probably be smack in the middle of my forehead).

I also very much like what you say about application to software design rather than UI design - although my software (from my background) has always been pretty minimalistic. That's what you get from building devices using a 6502 and NO RAM - but then even continuing, every byte of the footprint was really precious. It's a different background but boy does it teach you only to provide things that you know are going to get used...

Many thanks for the comments. I was sniggering to myself about a couple of user experience tests that would contribute to "Evidence-based Design" - a term I really like too - when Paul and I were working on UE testing on real consumers. These didn't quite make it into "Five Myths" - every byte of the footprint being precious I guess (old habits and all that) - the first being a classic one when the user got so upset with the device and service under test that it was just thrown across the table - along with some wonderful words that although I didn't understand well the spoken language I had no doubt of what they meant. The second being a developer leaving the control room with a similar amount of invective having seen his beloved system be somewhat less than successful with all the users that had been tested that morning. He failed to understand why we were testing on such a bunch of idiots! (the idiots - who weren't of course idiots - were carefully chosen to meet the profile). To be fair, eventually the particular developer got the point shortly afterwards and his design for consumers improved significantly.

Of course, not every development product has the general public as its market. But many of the principles still hold good. As an occasional user of published APIs and tools I'd particularly feel good if developers adopted the principle of making the most important things you do really easy to call and use, and simply documented so that a muggins like me can use them!

Hey - what do I know (I'm a chemist by training... but that was a LOOONG time ago)