In defense of software
Janet recently ran across a blog from one of her old colleagues at Red Hat from long ago, Paul McNamara. He posted an article about the "software complexity racket," in which he makes the case that software is routinely buggy and hard to use because software companies, keen to keep users beholden to them in maintenance contracts, have no incentive to actually make it simple and straightforward.
As one of those evil software industry people who perpetuate the cycle of complexity, I have to jump in and say a few words.
Certainly Paul is correct in asserting that software can be simple and elegant. He cites Google as the model of perfect simplicity, in both its software design and its business model. Fair enough. But the question is, should all software meet this same standard? And my immediate response is, absolutely not. Maybe if you're writing for a consumer-level, shrink-wrapped market, you should strive for the highest level of usability and bullet-proof behavior. But really . . . what proportion of all the software written is written for the consumer-level mass market? It must be less than 1%. No, most of the software complexity that companies deal with is self-inflicted . . . it's code they write for their own business systems. And the overwhelming complexity that you find in the shrink-wrapped software sold to businesses (Microsoft, Oracle, PeopleSoft, etc.) is strictly in response to the demands for complexity that come straight out of the business needs. Most people who use Excel, the industry-standard spreadsheet, only use a tiny percentage of its functionality . . . but you don't get to be the industry standard spreadsheet without having every inch of that complexity.
Unlike Paul, I don't necessarily see this as a bad thing. Of course, my bias is obvious -- I'm one of those Highly Paid Consultants who have a stake in the software complexity racket. But the simple fact is, software gets complex because people ask it to do complex things. It isn't that hard to get a business-oriented software package like Microsoft Office or GoldMine installed. All the fun begins when you start trying to make it conform to your real business processes.
Unfortunately, the legitimate call for better and simpler software sometimes masks another sin: corporate hubris. A few years ago Larry Ellison once up at an Oracle conference and told the world that, rather than spend all that money and time trying to force Oracle to conform to their business models, companies should just change all their business processes to conform with the way Oracle does things. Because, after all, Oracle knows best. And all the things you know about your own business? All the things you spent the last twenty years learning about your market and your customers, and learning how to serve them best? You know . . . the core of your competitive advantage, what makes you different from every other guy in the business? That's just evil software complexity. Such individuality cannot be tolerated.
There are some economics involved, as well . . . making something elegant and bullet-proof requires an awful lot of underlying complexity. Writing a utility to perform a specific job is one thing, but making it idiot-proof and total self-sufficient, with every possible exception and bug fully anticipated . . . that increases the complexity of the code by an order of magnitude. And most people aren't willing to pay for that level of quality. Sure, they say they want that level of quality, but when I tell them I can make something that will do the job for $1,000, or make something elegant and bulletproof for $10,000, they vote with their wallets. "Just make it do the job for now, and we'll call you if we need more."
The whole model of buying software once and then paying continually for improvements, fixes, support and enhancements . . . this didn't just spring out of Bill Gate's imagination. It is a model that evolved in response to the reality how software works and what people expect it to do, and how much they are willing to pay for it. And all the Googles in the world can't change that.
As one of those evil software industry people who perpetuate the cycle of complexity, I have to jump in and say a few words.
Certainly Paul is correct in asserting that software can be simple and elegant. He cites Google as the model of perfect simplicity, in both its software design and its business model. Fair enough. But the question is, should all software meet this same standard? And my immediate response is, absolutely not. Maybe if you're writing for a consumer-level, shrink-wrapped market, you should strive for the highest level of usability and bullet-proof behavior. But really . . . what proportion of all the software written is written for the consumer-level mass market? It must be less than 1%. No, most of the software complexity that companies deal with is self-inflicted . . . it's code they write for their own business systems. And the overwhelming complexity that you find in the shrink-wrapped software sold to businesses (Microsoft, Oracle, PeopleSoft, etc.) is strictly in response to the demands for complexity that come straight out of the business needs. Most people who use Excel, the industry-standard spreadsheet, only use a tiny percentage of its functionality . . . but you don't get to be the industry standard spreadsheet without having every inch of that complexity.
Unlike Paul, I don't necessarily see this as a bad thing. Of course, my bias is obvious -- I'm one of those Highly Paid Consultants who have a stake in the software complexity racket. But the simple fact is, software gets complex because people ask it to do complex things. It isn't that hard to get a business-oriented software package like Microsoft Office or GoldMine installed. All the fun begins when you start trying to make it conform to your real business processes.
Unfortunately, the legitimate call for better and simpler software sometimes masks another sin: corporate hubris. A few years ago Larry Ellison once up at an Oracle conference and told the world that, rather than spend all that money and time trying to force Oracle to conform to their business models, companies should just change all their business processes to conform with the way Oracle does things. Because, after all, Oracle knows best. And all the things you know about your own business? All the things you spent the last twenty years learning about your market and your customers, and learning how to serve them best? You know . . . the core of your competitive advantage, what makes you different from every other guy in the business? That's just evil software complexity. Such individuality cannot be tolerated.
There are some economics involved, as well . . . making something elegant and bullet-proof requires an awful lot of underlying complexity. Writing a utility to perform a specific job is one thing, but making it idiot-proof and total self-sufficient, with every possible exception and bug fully anticipated . . . that increases the complexity of the code by an order of magnitude. And most people aren't willing to pay for that level of quality. Sure, they say they want that level of quality, but when I tell them I can make something that will do the job for $1,000, or make something elegant and bulletproof for $10,000, they vote with their wallets. "Just make it do the job for now, and we'll call you if we need more."
The whole model of buying software once and then paying continually for improvements, fixes, support and enhancements . . . this didn't just spring out of Bill Gate's imagination. It is a model that evolved in response to the reality how software works and what people expect it to do, and how much they are willing to pay for it. And all the Googles in the world can't change that.
0 Comments:
Post a Comment
<< Home