I’ve worked on more than a few software projects over the decades and one of my favorite little misunderstandings is the Importance versus Effort disconnect. That’s where non-experts assume that because a particular part of a software system is more important than another, it must also take more effort to develop. That is rarely the case and, in fact, importance — however that is defined — is rarely a driving factor in determining effort or cost. This sort of misconception can result in some planning and budgeting mistakes, sometimes to comic or even tragic effect.
To illustrate, I can point to a trading system that I worked on (the names have been changed to protect the innocent). The average size of a transaction in this system was over $1 billion in 1990′s money. The part of the system that resolved the transactions was really really “important,” but the part of the system that allowed an application helpdesk to support users by seeing what their user’s saw cost 60% more to develop. That’s right, an “unimportant” helpdesk module was more expensive and took more effort and cost more than the “important” backend that handled billions of dollars a day.
There are lots of reasons why one system can be more expensive to develop than another. One recurring and important reason is the amount of user interface your application has. By that I mean a user interface for a real flesh and blood user. One of the reasons that the above trading platform had this mismatch was that while the helpdesk app had lots of user interface requirements, the trading backend had almost none. It dealt almost exclusively with other systems through API’s and data interchange protocols.
There’s lots of empirical evidence that interfaces for humans are more difficult and expensive to develop that those for machines, but there’s also a fair amount of theory on the subject under the heading of Human Computer Interaction (HCI). If you spend a little bit of time reading the referenced Wikipedia article, you’ll see that there’s an awful lot of cognitive psychology involved. In short, you can’t just ask a human being to do those things that a software system can do — parse 2GB of data, remember it forever and make decisions within a millisecond. No, human beings have limited memory, can’t act very fast, have ambitions and emotions and all sorts of human frailties. All of these have to be accounted and designed for.
(We ourselves use an approach known as User Experience Design (UXD) to tackled this terrain. It’s by no means the only approach, but it’s stood us in good stead.)
So, what are the key takeaways for product managers and owners? Don’t make emotional budgeting decisions. Just because your backend which is doing all of the financial transactions is important, doesn’t mean that it should cost more than the nifty website that helps users buy your product or service. Listen to your developers and analysts on the subject of effort and cost, then make rational decisions based on what is essential for your business.
