This is true especially today where I think most of us here have totally bought into release-quick-release-often mantra. That is absolutely good. But...on top of that mantra if you add an added condition for quality it will significantly give you an edge from another garage start-up that is on average not that worried about quality as about launching quick.
Now more than ever I think quality at launch matters as a point of product differentiation. Take that extra week to make the user experience better; or hunt out those odd bugs.
I agree that the point he brings up would greatly benefit the corporate world, but can the same be said of open source projects or startups? In general, these types of programmers seem to be perfectionists anyways, never feeling content until every possible feature is added. If, for them, the standard is "just right or nothing at all", I don't think anything would ever get released.
In summary, I think the article makes a good case study for the types of production that lend themselves to infrequent releases, but when your production model is based on evolutionary change, I think the "blank page approach" would be a bad idea.
I think hiring is the root cause behind this kind of "good enough" attitude. Most companies treat hiring as a chore to be got out of the way as quickly as possible. The people they hire treat their projects the same way. Mediocrity all around.
This is true especially today where I think most of us here have totally bought into release-quick-release-often mantra. That is absolutely good. But...on top of that mantra if you add an added condition for quality it will significantly give you an edge from another garage start-up that is on average not that worried about quality as about launching quick.
Now more than ever I think quality at launch matters as a point of product differentiation. Take that extra week to make the user experience better; or hunt out those odd bugs.