6 ms·

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical part

by delta1 9y ago

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Donald Knuth

microcolonel 9y ago
The problem is that these rules should apply in sequence to a given feature or flow, but they're instead applied in sequence to the whole product. So what happens is: they make everything "work", then they spend the next two decades pecking at making it right, and making it fast takes a back seat. Corollary: interaction latency, power consumption, and other performance characteristics should probably be part of "make it right", and "make it fast" might not even be a value at all.
Cthulhu_ 9y ago
The challenge there is that a lot of developers are pushed by their managers to go to the next feature after #1, postponing 2 and 3 for when there's time. Time to market is considered the most important thing. Of course, it accumulates after a year.
- zimpenfish 9y ago
  > pushed by their managers to go to the next feature Understandable, though, since features are what get customers to pay - 99% of customers will not care about efficient code as long as they can achieve what they're after without screaming.
  - hasenj 9y ago
    Things that are full of bugs and are sluggishly slow are what makes customers scream their lounges out 99% of the time.
hasenj 9y ago
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) 2. Make it even faster 3. Make it better
- zimpenfish 9y ago
  > 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.
  - hasenj 9y ago
    There's no evidence than any of this is true. 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.
cjsuk 9y ago
1. Make it work 2. Make it ... err actually fuck it, let's build a hairball on top of it. That's how it really rolls. You have to think it fast, think it right, then make it work because if you do it the other way round, it never happens.
- delta1 9y ago
  You're conflating management and priority issues with programming issues.
  - cjsuk 9y ago
    The two are intertwined and inseparable.

by delta1 9y ago

microcolonel 9y ago

The problem is that these rules should apply in sequence to a given feature or flow, but they're instead applied in sequence to the whole product. So what happens is: they make everything "work", then they spend the next two decades pecking at making it right, and making it fast takes a back seat. Corollary: interaction latency, power consumption, and other performance characteristics should probably be part of "make it right", and "make it fast" might not even be a value at all.

Cthulhu_ 9y ago

The challenge there is that a lot of developers are pushed by their managers to go to the next feature after #1, postponing 2 and 3 for when there's time. Time to market is considered the most important thing. Of course, it accumulates after a year.

zimpenfish 9y ago
> pushed by their managers to go to the next feature Understandable, though, since features are what get customers to pay - 99% of customers will not care about efficient code as long as they can achieve what they're after without screaming.
- hasenj 9y ago
  Things that are full of bugs and are sluggishly slow are what makes customers scream their lounges out 99% of the time.

hasenj 9y ago

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) 2. Make it even faster 3. Make it better

zimpenfish 9y ago
> 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.
- hasenj 9y ago
  There's no evidence than any of this is true. 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.

cjsuk 9y ago

1. Make it work 2. Make it ... err actually fuck it, let's build a hairball on top of it. That's how it really rolls. You have to think it fast, think it right, then make it work because if you do it the other way round, it never happens.

delta1 9y ago
You're conflating management and priority issues with programming issues.
- cjsuk 9y ago
  The two are intertwined and inseparable.