6 ms·

I wonder how heavily other fields sacrifice in the name of "ease of implementation". Could we have houses that are 100x stronger and longer lasting if we allow

I wonder how heavily other fields sacrifice in the name of "ease of implementation". Could we have houses that are 100x stronger and longer lasting if we allowed a few extra weeks of construction time? Could we 10x battery capacity with a slightly more sophisticated manufacturing process? I don't think many developers nowadays understand how fast computers are, nor how much needless bloat is in their software.

ajmurmann 4y ago
For the economics of that comparison to make sense, we should also include material inputs to the construction. It doesn't matter to the cost of the final product if it was materials that were saved or labor cost. Software is the special case where cost almost entirely comes down to labor. So given that, we are of course constantly compromising quality. We realize that less though because buildings are more standardized.
TimPC 4y ago
The big issue in other fields mostly isn't manufacturing design or construction process. The main bottleneck is with physical goods and long distances travelled you're subject to high shipping costs so people cut all sorts of corners to make things less bulky and lighter. Cheap plastics are far lighter than wood or metals for instance so we see more plastics get used.
adamdusty 4y ago
I work in III/V semiconductors. The product development goes like: identify need, design, attempt a proof of concept, DoEs to determine manufacturing costs/viability, repeat until you have a statistically controlled viable process. There is essentially no room for technical creativity like there is in software. If we spent an extra year on our worst performing product (we've done this), we would get at best 5% improvement with iffy reproducibility. I dont know about construction or batteries.
astrange 4y ago
You could have a lot more good enough and much cheaper houses in the US, but we banned manufactured/prefab houses due to lobbying from the “build everything individually out of wood” lobby, require huge setbacks due to the front lawn lobby, and various other things like overly wide roads because of out of date fire codes.
mr_toad 4y ago
> I don't think many developers nowadays understand how fast computers are, nor how much needless bloat is in their software. Most, as in > 50%, of developers aren’t in a position to decide which languages, libraries and tools to use, or how much time they can spend on performance improvement.
Gigachad 4y ago
Anyone with APM setup can see what’s going on pretty well. For almost all web apps, you can see that ruby/python are extremely fast and almost all of the time spent on a request is the database.
- dgb23 4y ago
  The implication is likely that the db does all the work, and the parts in ruby/python have barely anything to do.
  - Gigachad 4y ago
    This is true of every rails app I have worked on in the last 10 years. You’d have to be doing something remarkably bad or have some crazy situation to end up with ruby using any noticeable amount of compute time.
    - dgb23 4y ago
      Well that depends on what your application is doing. But yes, if it is a database heavy workload, then what you say applies. What I was trying to get at was that in these cases the ruby/python/whatever parts are not actually fast, they just do much less stuff. Add that the database might be on another machine, so there's plenty of overhead as well. Aside: You can sometimes get orders of magnitude of speed gains just by using an embedded database and a fast language on top if your workload allows it. Essentially you don't really do much to get this, just cut overhead.

ajmurmann 4y ago

For the economics of that comparison to make sense, we should also include material inputs to the construction. It doesn't matter to the cost of the final product if it was materials that were saved or labor cost. Software is the special case where cost almost entirely comes down to labor. So given that, we are of course constantly compromising quality. We realize that less though because buildings are more standardized.

TimPC 4y ago

The big issue in other fields mostly isn't manufacturing design or construction process. The main bottleneck is with physical goods and long distances travelled you're subject to high shipping costs so people cut all sorts of corners to make things less bulky and lighter. Cheap plastics are far lighter than wood or metals for instance so we see more plastics get used.

adamdusty 4y ago

I work in III/V semiconductors. The product development goes like: identify need, design, attempt a proof of concept, DoEs to determine manufacturing costs/viability, repeat until you have a statistically controlled viable process. There is essentially no room for technical creativity like there is in software. If we spent an extra year on our worst performing product (we've done this), we would get at best 5% improvement with iffy reproducibility. I dont know about construction or batteries.

astrange 4y ago

You could have a lot more good enough and much cheaper houses in the US, but we banned manufactured/prefab houses due to lobbying from the “build everything individually out of wood” lobby, require huge setbacks due to the front lawn lobby, and various other things like overly wide roads because of out of date fire codes.

mr_toad 4y ago

> I don't think many developers nowadays understand how fast computers are, nor how much needless bloat is in their software. Most, as in > 50%, of developers aren’t in a position to decide which languages, libraries and tools to use, or how much time they can spend on performance improvement.

Gigachad 4y ago

Anyone with APM setup can see what’s going on pretty well. For almost all web apps, you can see that ruby/python are extremely fast and almost all of the time spent on a request is the database.

dgb23 4y ago
The implication is likely that the db does all the work, and the parts in ruby/python have barely anything to do.
- Gigachad 4y ago
  This is true of every rails app I have worked on in the last 10 years. You’d have to be doing something remarkably bad or have some crazy situation to end up with ruby using any noticeable amount of compute time.
  - dgb23 4y ago
    Well that depends on what your application is doing. But yes, if it is a database heavy workload, then what you say applies. What I was trying to get at was that in these cases the ruby/python/whatever parts are not actually fast, they just do much less stuff. Add that the database might be on another machine, so there's plenty of overhead as well. Aside: You can sometimes get orders of magnitude of speed gains just by using an embedded database and a fast language on top if your workload allows it. Essentially you don't really do much to get this, just cut overhead.