As programmers, most of us want to build things better, faster and cheaper. We are taught big O analysis in our first algorithms course, we never give up optimizing. We love projects that relentlessly simplify. We find compact and powerful languages attractive and surely the next language is better than the previous one. We always want to do more with less, but if we do more with less, shouldn’t it be cheaper too ? Yes! we answer and most of the time we are wrong. Better, faster are great goals but cheaper does not pay the bills.

Let us look at the variations, there is better, faster and costlier. This one makes for a great (arguably, the best) business model. Intuitively, it makes some sense, as human beings we are irrational and emotions trump reason frequently. Evoke strong positive emotions and people will gladly pay you a premium. A lot of great engineering has to go into these products though, it is not just about looking good. If a software company can pull this one off, it is the best way to get rich. The problem is that other programmers are constantly looking to making your product better, faster and cheaper. Eventually, your product will become a commodity.

There is worse, slower and cheaper. This one is also easy to understand, you get what you pay for. If you can churn widgets out quickly and for a lower cost, you can make money on volume. I don’t think software manufacturers have figured out how to make money with this model. The closest I have seen this work is the discount bin for computer games at the local electronics store. A number of hardware manufacturers on the other hand thrive this way.

Then there is worse, slower and costlier. This is the most confusing business model because it just should not work (in theory). And yet, it does. No product starts out this way, they all start out in the better, faster and costlier mode. On the road to commoditization, some successful products end up in this state. The reasons vary, in becoming successful, some products become monopolies. Some of them are part of very complex software systems and complexity resists change. There are probably other reasons involving human factors. This state can last anywhere between a couple of months to a few decades. No one can predict the duration. The complexities of macro economic systems are unfathomable.

This state is a programmers worst problem, because we are supposed to make things better, faster and cheaper. But, remember, cheaper does not pay the bills.

The best way to kill a nascent debate is to use the line “if you think I am wrong, prove it”. This is one of the most clever ways to avoid criticism (constructive or otherwise). It does not quite close the door on dissent, while effectively slamming it shut.

The problem is that something has to be provable for anyone to prove it. Proving also requires a lot of effort or a lot of time. So, the next time you need to make a controversial decision, make the decision and then use the line if you think I am wrong, prove it. In all likelihood, your decision will stay.

Of course, you still have to be right…….and time will surely tell.