Most people that complain about shipping the imperfect solution are not aware how inefficient is striving for perfection in the software world. Personally, I ha

Most people that complain about shipping the imperfect solution are not aware how inefficient is striving for perfection in the software world. Personally, I have never seen rumination on every nook-and-corner of the product yielding something fruitful. In fact, it invariably results in the opposite — solving the wrong problems and then, solving the real problems that you never thought would've existed. Rinse. Repeat. The author equates imperfection to sloppiness but I'd argue that the case is quite the opposite. I recall a comment made by Paul Buchheit on Hacker News about FriendFeed — "Another interesting detail is that this is roughly the 4th iteration on the FriendFeed backend since we launched 17 months ago. If you look at the the graphs at the bottom of Bret's post, you can see that our previous system was about to die -- average pageview latency had increased from about 135ms to 260ms in less than a month! (not a good trend) This new design also accommodates some important upcoming features that would have been problematic in the old system. This experience reinforces my belief that it's better to be quick than brilliant. If we had wasted a lot of time trying to build some really smart, super-scalable system right from the start, it would have inevitably been over-optimized for the wrong things, since the product and requirements have changed quite a bit since launch."