Newton, Darwin, ISP's, and Software
It's Friday night when I'm writing this and the power's been out due to a big windstorm for more than 12 hours. I live in the country and get my water from a community well, so no electricity = no water, which is a significant problem after a while. The infrastructure out here is old and above ground and coupled with lots of trees it means that power outages are common in winter. After 16 years I'm used to them.
It's about 2 am and as I think about how dark it is with no lights even from my neighbors I wonder if the nice folks at Puget Sound Energy are up all night working to restore them. They ought to be. I'm reminded of something I read years ago. Some research into employee compensation showed that people aren't motivated by big salaries, but are demotivated by low ones. So if you have two employees, Jane and John, and you pay Jane $80,000 and John $40,000, Jane isn't going to work twice as hard or be twice as motivated or even twice as grateful as John. But you can count on John being ticked off. What's that got to do with no lights?
A few months ago I was meeting with a company that's basically an ISP. They wanted to grow market share and had decided that their top level message was their 99+ percent up time. I told them that position was worthless, because ISP's were like a utility company. When you turn on the tap, you expect water. When you flick the switch, you expect the lights. It's not good enough to flick the switch and get lights 99+ percent of the time. In situations like this, 100 per cent performance is the minimum requirement for satisfaction. At 2 am with the lights out and no way to flush my toilets, It's not ok with me that most of the time the power is on.
It's really Darwin's fault. Well, Newton's, anyway. Before Newton wrote his description of the physical laws of the universe people just assumed everything that happened was God's will. Later Darwin completely undermined the teachings of the Church by challenging the widely held Genesis story of the origins of life. The fact that the Bible didn't mention dinosaurs, fossils, or evolution threw a big monkey wrench into people's perceptions of their universes.
Before you start wondering if I've been hitting the leftover eggnog a little too hard before bed, let me tie all this to software. Too often we might think that ok is good enough, but it's not. In this post-enlightenment age, we believe in systems and rules. Science and technology have replaced God over the last 300 years as the causality of the universe. Where before people would go to the priest to get advice and explanations, today people have to turn to the help desk and documentation. Unfortunately for those of us creating technology and counting on it for our livings, there's no modern equivalent to “It's God's will.” Tornados and earthquakes may still be the province of the Almighty, but if your app crashes and a customer loses data, it's you they'll blame, not God. And just as they didn't understand God's ways, they don't understand your technology. As a consequence, they expect it—like the lights—to work.
Think back to the salary example and the power company. Software is no different. No one will ever be happy because a product doesn't crash, they'll just avoid being unhappy. That gets them to neutral, which isn't enough to secure lifetime customers and gain referrals. Customers will avoid products that crash in favor of ones that don't, but that doesn't make them satisfied. It's easy to get fixated on coolness stuff like new features, but they won't buy you much in the market if you haven't taken care of the basics.
So some advice, naturally:
- Make sure your stuff really works. In the words of Guy Kawasaki, get a better reality. This sounds simple but it's not. You just can't test too much, and no matter how much you test in-house, the time the product is with real customers is what really counts. Getting hard crash or failure data from them, even after product ship, is best. The automated error reporting that Windows XP does is a move in the right direction. Can you do something similar?
- A bug, crash, or failure in your product is bad enough. What happens next is critical. How extensive is your troubleshooting help, both in documentation and wizards? How good are your tech support people? What are the options available to the customer for support? Do they include 800 numbers, staffed over generous hours? Or are they based on a toll call during “normal” office hours? Are you one of these companies trying to get customers to build support communities? How do your customers like it? How successful is it? What are you doing to make it really work?
- Find out what people really think. Hire a third party research firm to survey your customers and ask the really tough questions. Then act on the information you receive.
- Eat your own dogfood. And eat your competitor's, too. Automobile engineers have to drive to work, and you can bet they do it in their own company's cars. In software that can be hard: when I worked on compilers we used our product to build itself, but not all software engineers can also be active domain users: it's unlikely that the Photoshop development team at Adobe are all working full time as graphic artists. You know they spend time editing their own vacation photos and the like, but it's not the same as using a tool to earn your living.
Good luck: it's not an easy goal. But computers and software are just too hard, still, and too fragile. All of us need to be diligent about making stuff better. It needs to be as reliable as the lights.
Better, even.
