5 ms·

This "make it work" adage makes no sense at all when scrutinized. Does anyone believe that other industries think like that? First let's invent a washing machi

by blub 9y ago

This "make it work" adage makes no sense at all when scrutinized. Does anyone believe that other industries think like that? First let's invent a washing machine that washes, but occasionally sets clothes on fire and takes 24h for a washing cycle. Then we'll redesign it so it doesn't set things on fire, and finally redesign it yet again to finish in 2h. It's incredibly wasteful. For any complex project, making it work and fast only at the end will either result in massive cost overruns or an outright canceled project.

lmm 9y ago
> Does anyone believe that other industries think like that? Software is very unlike other industries. > For any complex project, making it work and fast only at the end will either result in massive cost overruns or an outright canceled project. Citation needed, because my experience is the exact opposite: projects that put effort into making it fast from the first never get off the ground.
- blub 9y ago
  Software is different, but it doesn't bend space and time. Redesign costs can be significantly cheaper, but they are still present, and if the project is complex enough can be just as high as in physical world project catastrophes. I assume you have heard of various software projects which cost millions and overshot their budget by 50%, 100%, 200%, etc... Now regarding the make -> work -> fast cliché: I tend to have architectural discussions at the beginning of the project, which include among other things performance. Depending on the project it might be a surface discussion, or go deeper. Then based on the performance requirements and design decisions, the system is implemented, performance is tracked and adjustments are made. So performance should not be put first, middle or last, it's an architectural level concern which is controlled throughout the project. How do those of us that like to complain about "premature optimisation" whenever performance is discussed design software? Because based on HN discussions it looks like code & pray.
  - lmm 9y ago
    > Redesign costs can be significantly cheaper, but they are still present, and if the project is complex enough can be just as high as in physical world project catastrophes. I assume you have heard of various software projects which cost millions and overshot their budget by 50%, 100%, 200%, etc... Indeed; in my experience such failures tend to be caused by too much rather than too little design and architecture up front. > How do those of us that like to complain about "premature optimisation" whenever performance is discussed design software? Because based on HN discussions it looks like code & pray. Don't try to design at the start when you don't know anything; let the design emerge. Do the simplest thing that might possibly work; 90% of the time it does work, the other 10% of the time you learn about another constraint. Get the simplest use case working, then iteratively expand to the full functionality. Refactor continuously and fearlessly (and adopt whatever testing/verification practices you need to make it fearless), driven by the changes that you need to make. It's easy to mock, but it works much better than trying to design as a separate activity.
brians 9y ago
Yeah. Speed is the dominant cost in software, but other industries treat other costs similarly. To pick another darling, look at Tesla: the Roadster is expensive, flammable, suitable only for enthusiasts. The S is generally useful, but too expansive. Still a narrow market. The E is their first general purpose product. That’s normal. Same deal with Apple II, Mac, iPhone. Same deal with ether, coarse general anesthetic, modern mixes. Yes, this is completely normal, and software based products should expect to evolve similarly.
- blub 9y ago
  All of the things you mentioned worked and had good enough performance. There was no crappy version of the iPhone which ran out of battery in 1h and took seconds to refresh when scrolling. So obviously they thought about the performance aspect from the start.
  - dagw 9y ago
    There was no crappy version of the iPhone which ran out of battery in 1h and took seconds to refresh when scrolling. I'm pretty sure there probably was. They where just smart enough to make sure the only people that saw that version where a handful of engineers in their R&D lab.
dagw 9y ago
"Make it work, make it right, make it fast" should primarily be applied in the context of individual functions and modules not whole complex projects. Don't start micro-optimizing your function for speed before you've gotten it to return the correct result. Also with the additional caveat that you should stop at make it work right until you're at least fairly sure that that function is actually important for overall performance.
zild3d 9y ago
Yes. It's the prototyping phase. Medicine, hardware, even food. Cliff made his energy bars "work" first in his kitchen, then started to figure out how to make them scalable and optimized for taste, etc. Any hardware startup does the same. Get a giant, hulky prototype going, with shotty wiring, way too much weight, and get it working. This make it work first adage is because you don't know what the final product/project will need to be (e.g. do it in python and then figure out how to make it better)
- blub 9y ago
  Ah food. I believe Soylent was experimenting with this idea of make it work and then make it work right, which resulted in a lot of entertainment for those that read the toilet stories of Soylent customers. I don't see why there has to be a hard cut between make it work and make it work right or fast in prototyping. With more thought, perhaps the product can already be largely right and fast enough and also easily improvable. I can't help but look at this saying as an excuse to get something done fast with the hope it can be improved later. This is not a general truth.

by blub 9y ago

lmm 9y ago

> Does anyone believe that other industries think like that? Software is very unlike other industries. > For any complex project, making it work and fast only at the end will either result in massive cost overruns or an outright canceled project. Citation needed, because my experience is the exact opposite: projects that put effort into making it fast from the first never get off the ground.

blub 9y ago
Software is different, but it doesn't bend space and time. Redesign costs can be significantly cheaper, but they are still present, and if the project is complex enough can be just as high as in physical world project catastrophes. I assume you have heard of various software projects which cost millions and overshot their budget by 50%, 100%, 200%, etc... Now regarding the make -> work -> fast cliché: I tend to have architectural discussions at the beginning of the project, which include among other things performance. Depending on the project it might be a surface discussion, or go deeper. Then based on the performance requirements and design decisions, the system is implemented, performance is tracked and adjustments are made. So performance should not be put first, middle or last, it's an architectural level concern which is controlled throughout the project. How do those of us that like to complain about "premature optimisation" whenever performance is discussed design software? Because based on HN discussions it looks like code & pray.
- lmm 9y ago
  > Redesign costs can be significantly cheaper, but they are still present, and if the project is complex enough can be just as high as in physical world project catastrophes. I assume you have heard of various software projects which cost millions and overshot their budget by 50%, 100%, 200%, etc... Indeed; in my experience such failures tend to be caused by too much rather than too little design and architecture up front. > How do those of us that like to complain about "premature optimisation" whenever performance is discussed design software? Because based on HN discussions it looks like code & pray. Don't try to design at the start when you don't know anything; let the design emerge. Do the simplest thing that might possibly work; 90% of the time it does work, the other 10% of the time you learn about another constraint. Get the simplest use case working, then iteratively expand to the full functionality. Refactor continuously and fearlessly (and adopt whatever testing/verification practices you need to make it fearless), driven by the changes that you need to make. It's easy to mock, but it works much better than trying to design as a separate activity.

brians 9y ago

Yeah. Speed is the dominant cost in software, but other industries treat other costs similarly. To pick another darling, look at Tesla: the Roadster is expensive, flammable, suitable only for enthusiasts. The S is generally useful, but too expansive. Still a narrow market. The E is their first general purpose product. That’s normal. Same deal with Apple II, Mac, iPhone. Same deal with ether, coarse general anesthetic, modern mixes. Yes, this is completely normal, and software based products should expect to evolve similarly.

blub 9y ago
All of the things you mentioned worked and had good enough performance. There was no crappy version of the iPhone which ran out of battery in 1h and took seconds to refresh when scrolling. So obviously they thought about the performance aspect from the start.
- dagw 9y ago
  There was no crappy version of the iPhone which ran out of battery in 1h and took seconds to refresh when scrolling. I'm pretty sure there probably was. They where just smart enough to make sure the only people that saw that version where a handful of engineers in their R&D lab.

dagw 9y ago

"Make it work, make it right, make it fast" should primarily be applied in the context of individual functions and modules not whole complex projects. Don't start micro-optimizing your function for speed before you've gotten it to return the correct result. Also with the additional caveat that you should stop at make it work right until you're at least fairly sure that that function is actually important for overall performance.

zild3d 9y ago

Yes. It's the prototyping phase. Medicine, hardware, even food. Cliff made his energy bars "work" first in his kitchen, then started to figure out how to make them scalable and optimized for taste, etc. Any hardware startup does the same. Get a giant, hulky prototype going, with shotty wiring, way too much weight, and get it working. This make it work first adage is because you don't know what the final product/project will need to be (e.g. do it in python and then figure out how to make it better)

blub 9y ago
Ah food. I believe Soylent was experimenting with this idea of make it work and then make it work right, which resulted in a lot of entertainment for those that read the toilet stories of Soylent customers. I don't see why there has to be a hard cut between make it work and make it work right or fast in prototyping. With more thought, perhaps the product can already be largely right and fast enough and also easily improvable. I can't help but look at this saying as an excuse to get something done fast with the hope it can be improved later. This is not a general truth.