Tech & Work

Develop applications that empower users

Kathy Sierra's recent presentation on user empowerment reminds Justin James that developers need to consider how an application will make their users better.

The Business of Software 2012 conference opened with Kathy Sierra giving a really good talk about user empowerment. Her basic premise was simple: Users do not use your application for the sake of using your application -- they use it because it benefits them in some way. This should seem obvious, but it is easy for developers to forget. We get hung up on details that do not help to achieve this goal all the time, whether it be a massive argument over inter architectural decisions or adding new features without any validation they are needed.

I have become increasingly aware that code is a commodity. Yes, it is a tough commodity to get at a high level of quality, but we are at a point where most applications are not that difficult to assemble to a "minimum viable product" (MVP) standard. Sure, taking it from MVP to be totally tweaked and able to dominate the market is often a long, hard road. But if you look around, tons of applications were not spectacular when they started their ascendency to the top. The original iPhone was not terribly good, but it was the first smartphone to really be useful and usable for average people. Android 2.0 that shipped on the Motorola Droid was not very good in my experience, but it did the job well enough to compete with the iPhone of the era. Windows 3.1 and Office 4.3? Check and check. Visual Basic 3.0? Don't get me started.

It is clear that a technically unsound product can create a market; in fact, some of those technically unsound products come to dominate existing markets and defeat existing incumbents. How does this happen? It happens because technical considerations are almost never at the top of the stack in decision making. Kathy's speech really highlighted this for me: Users really only care about what makes them better. When cell phones first become somewhat affordable in the mid '90s, they were not very good, but people bought them because having a cell phone that was not very good was a lot better than not having one at all, and it expanded your ability to work. All of those hours that were previously wasted on driving or otherwise being out of the office suddenly became productive hours. The smartphone has done the same thing.

As developers, we need to learn to take a step back and ask ourselves, how does this make our users better? Does it improve their lives? Does this give them something to show off to their friends? Does this help them do their jobs better? If the answer is "no," then the next question has to be "why are we doing it?"

This is not to discount the value of things like sound application architecture, but these things need to be done within the context of "how does this make our users better?" Gold plating features and internal improvements without validating how they help you with your real end goals is a waste of time. I have been there. For example, I've been in numerous arguments about whether a method should return null or throw an exception in certain circumstances. Did it make our users better? Not at all. Even the technical differences didn't matter in the long run.

As developers, we need to start learning to be ruthless about making our users better. Again, the code itself is a commodity. If we do not do it, our competitors will, and we will find ourselves losing users and market share to them even if we have technical superiority.

If you have the time, you should read the summary of Kathy's talk when it gets posted on the Business of Software blog.


Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.


Justin James is the Lead Architect for Conigent.


You're both missing the underlying point of the blog. You have to understand what the user is trying to accomplish before you decide what tools to use. You don't build a house without blueprints. And you don't just select the first set of blueprints off the shelf and tell the buyer THIS is what we're building. Even subdivisions give the buyer a choice of floor plans. By deciding the tools before knowing the project just leads to trouble.

HAL 9000
HAL 9000

Is making their Apps Cross Platform so that their users are no longer forced to use a Single Platform. That way the customers can move from one platform to another and keep their existing Apps or at the very least continue using the same app without any need to learn anything new. That is where I see the current generation of the Less than Perfects App winning. Col

Sterling chip Camden
Sterling chip Camden

and I miss her blog "Creating Passionate Users." I agree with your point, but I also think it's important to acquire the right tools when those tools help you to do a better job of making your users successful. That is, if they help you deliver faster, or with better quality, or with more features, etc. That means that you might adopt a language like Haskell, not because it's what the cool kids use, but because it actually helps you create a better experience for your users.

Editor's Picks