This quote is so misunderstood and so abused all the time.
The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how.
It's not a rallying call to forgo all concerns about application performance and efficiency.
The mis-application of this quote is the root of all evil in modern software IMO.
It's why a chat program takes 500MB of RAM and why many programs take 10 seconds to load even though there's no technical reason they cannot startup instantly.
You should make it right and fast from the very start. You should not make something that "works" but is full of bugs and slow as hell. Like, that makes no sense at all. If it's full of bugs then it doesn't work. If it's slow as hell then it doesn't work.
1. Make it work correctly and efficiently (to a reasonable degree)
> 1. Make it work correctly and efficiently (to a reasonable degree)
Unfortunately, this took your team 6 months and the people that launched their app 4 months ago (having opted for "make it work") now have 90% of your market and you've all just been made redundant because the customers do not care whether your app is "more correct" and "more efficient" because they just plain damn couldn't use it.
There's a reason "worse is better" applies to software.
First market is not often the winner. Facebook came very late to the social media scene but it dominated.
Google came very late to the search engine scene, and people don't even remember this but there was a time when there were a ton of search engines and anyone at the time would probably think that the search engine market is saturated and there's no space for a new product.
All evidence actually points to better products dominating the market even if they come late.
If your competitors released their app 4 months ahead of you but it was full of bugs and always hangs up, and then you release your product which actually works and performs well, people will see your product as a breath of fresh air.
Another example is the Chrome browser, which came at a time when Firefox and IE were competing fiercely for market share, and Chrome completely dominated them on the simple basis that it was _really fast_.
For most products it doesn't even cost 6 months to make it fast. If you have that as a goal from the very start, there will never be a stage of "omg it's really slow let's try to make it a bit faster". It will always just be fast.
> Chrome completely dominated them on the simple basis that it was _really fast_.
It isn't that simple - a lot of Chrome's success came because they "made it work" in ways that Firefox (horribly wasteful of CPU, memory, battery life) and IE (shambles in every department) didn't. Also helped in large part by having an enormous web monopoly pushing it and favouring it for their properties.
But you're definitely right that it came after them.
> Yes, it performed way better than Firefox, which is exactly my point.
No, you specifically called out the speed and speed only - "on the simple basis that it was _really fast_" - nothing about it working right in other areas (which are the ones that grabbed people, not the speed.)
The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how.
It's not a rallying call to forgo all concerns about application performance and efficiency.
The mis-application of this quote is the root of all evil in modern software IMO.
It's why a chat program takes 500MB of RAM and why many programs take 10 seconds to load even though there's no technical reason they cannot startup instantly.
You should make it right and fast from the very start. You should not make something that "works" but is full of bugs and slow as hell. Like, that makes no sense at all. If it's full of bugs then it doesn't work. If it's slow as hell then it doesn't work.
1. Make it work correctly and efficiently (to a reasonable degree)
2. Make it even faster
3. Make it better