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.
J.JaKeep 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.