I don't disagree with anything PB says. I say to do hard things if they benefit the user proportionately. He says not to do hard things just because they're impressive. Since in practice impressing people (including oneself) is the main reason people do hard things that don't benefit users, these two principles yield the same advice.
paul says that the way to build successful products is to avoid hard problems:<p><a href="http://paulbuchheit.blogspot.com/2007/04/secret-to-making-things-easy-avoid-hard.html" rel="nofollow">http://paulbuchheit.blogspot.com/2007/04/secret-to-making-things-easy-avoid-hard.html</a>
<a href="http://news.ycombinator.com/comments?id=16409" rel="nofollow">http://news.ycombinator.com/comments?id=16409</a>
<a href="http://news.ycombinator.com/comments?id=17040" rel="nofollow">http://news.ycombinator.com/comments?id=17040</a><p>That made a lot of sense to me. But on the other hand, pg's "How to Make Wealth" makes a good argument for precisely the opposite view:<p>"Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him. What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty, we'd always take the harder one."<p><a href="http://paulgraham.com/wealth.html" rel="nofollow">http://paulgraham.com/wealth.html</a><p>Of course, no piece of general advice is right in all cases. But what should you look for, in a given situation, to know whether it's better to seek out the hard problems or better to avoid them?