2006-08-06: Taking The Hard Way OutTaking The Hard Way Out
One thing that has bothered me for a long time was a comment in a lecture by famed Waterloo economics professor Larry Smith. To paraphrase, he said there are a lot of big problem areas in business that need solving that are just ignored. Meanwhile, everyone in the computer industry seems to have a fatal attraction a particular other set of problems, which they solve over and over again.
The example he gave at the time was Windows vs. Linux: who would want to start a company to compete with Microsoft in this day and age? Even if you did manage to win (or even to not die), it would just be so much work! And no, the irony was not lost on me at that point in my entrepreneurial career.
My answer to his question at the time? Well, some projects are just more interesting than others, and I want my career to be interesting. It was abundantly clear to me even then that going into, say, banking software was the way to make loads of money, because the customers are rich and (it was a y2k madness at the time) boy, do they ever have lots of easy problems to solve. But banking software was by no means interesting. So I elected to take the path more travelled, as it were, and go for technical challenge instead of easy megaprofits. In other words, a compromise. I even formed a little continuum in my mind of different kinds of programming projects, in which the most technically challenging ones (hardest I could think of: video games) are the least profitable for the developer. And vice versa: banking software has got to be some of the least technically difficult software in the universe, and attracts some of the very worst programmers, who then get paid a lot to work reasonable hours with very low stress.
But the fact is that I'd be more than pleased to increase my stress levels a bit in exchange for an interesting project. That much isn't a compromise; in fact, too little stress is downright boring. That's why the best developers gravitate toward harder projects instead of easier ones. Video game developers know perfectly well what they're getting into before they start. They're buying into a whole lifestyle.
Well, good for them. I wasn't quite willing to go as far as the insane working conditions in the gaming industry, but I still wanted challenge, and operating systems seemed fun. There was stress, but that's not a compromise, because I wanted stress.
The compromise was the profits. Say what you like, and I do dearly love the free software community, but making massive quantities of money is a great way to make an already-fun company even more fun.
So what's the non-compromise solution in this case? Well, the form of the solution is obvious enough: it must be highly profitable but also challenging and difficult so that it can be fun.
It's pretty hard to take something that's challenging and difficult and not very profitable, and then make it highly profitable. Profits don't just magically appear just because you did something that was difficult. If it was the wrong difficult project, you're still out of luck.
But what about taking something profitable and making it difficult? Why, you can take just about anything and make it difficult if you try hard enough!
Of course, it would be best if the difficulty were actually warranted in some way, for example, to make the product even more profitable, or to also make the world a better place, or whatever. But that's actually only a secondary requirement. Look how much fun we had revamping our knowledgebase, for example.
So what if I could find a useful way to make, say, banking software challenging and fun?