3 ms·

I think I agree with you but disagree with the article. > But because of the things called out in this article, these magical tools and technologies are plague

I think I agree with you but disagree with the article. > But because of the things called out in this article, these magical tools and technologies are plagued by endless amounts of things that just don't work right, break randomly, and fail in unexpected ways. There is way more software out there than one can even imagine responsible for literally every aspect of human society. There is an insatiable need for more software and there simply isn't enough software developers in the world to do it all. What you get is triage -- things half baked because of effort. There isn't some problem specific to software with regards to physical constraints. Cheap stuff made quickly breaks whether it's software or power tools or children's toys. It's that simple. > And that was because Steve Jobs was the forcing function on quality. Exactly. What does that have to do with abstractions or the lack of physical constraints?

croemer 2y ago
I just wanted to thank you two here. Your dialog is so insightful. I think the original article was bad. It's biggest merit is that it got you two together here in the comments!
jdbernard 2y ago
Yes, I think broadly we agree. Thanks for the discussion. > What does that have to do with abstractions or the lack of physical constraints? Someone like Steve Jobs becomes a forcing function to maintain a high bar of quality. He's the exception that proves the rule. In the general case you can't rely on someone like Steve Jobs, but in other domains you still have a higher minimal quality bar driven by physical constraints. I concede that in every domain it is true that "cheap stuff made quickly breaks." My argument is that even then there is a minimal bar that is set by physical constraints. If the bridge doesn't stand it doesn't get built. If you cut too many corners or rush too much it just doesn't get built, or has to be rebuilt. This leads to overages and delay, but at the end of the process the bridge meets the physical specs or it falls over. I think the lack of any such physical constraints means that there is no such minimal bar for software and the floor of quality is therefore much lower, even in software by large, successful, and well-funded, "marquee" companies.
- wvenable 2y ago
  That seems like an arbitrary distinction. Plenty of software gets built that doesn't meet the minimal standards -- and you know what happens? It doesn't get deployed. How is that different from the bridge that doesn't get built or falls over? All the same factors are at play: poor planning, insufficient resources, bad management, inexperienced workers, insufficient funding, lack of testing. Plenty of construction projects have corners cut. Just like with software, it is someone's job to patch it later.

croemer 2y ago

I just wanted to thank you two here. Your dialog is so insightful. I think the original article was bad. It's biggest merit is that it got you two together here in the comments!

jdbernard 2y ago

Yes, I think broadly we agree. Thanks for the discussion. > What does that have to do with abstractions or the lack of physical constraints? Someone like Steve Jobs becomes a forcing function to maintain a high bar of quality. He's the exception that proves the rule. In the general case you can't rely on someone like Steve Jobs, but in other domains you still have a higher minimal quality bar driven by physical constraints. I concede that in every domain it is true that "cheap stuff made quickly breaks." My argument is that even then there is a minimal bar that is set by physical constraints. If the bridge doesn't stand it doesn't get built. If you cut too many corners or rush too much it just doesn't get built, or has to be rebuilt. This leads to overages and delay, but at the end of the process the bridge meets the physical specs or it falls over. I think the lack of any such physical constraints means that there is no such minimal bar for software and the floor of quality is therefore much lower, even in software by large, successful, and well-funded, "marquee" companies.

wvenable 2y ago
That seems like an arbitrary distinction. Plenty of software gets built that doesn't meet the minimal standards -- and you know what happens? It doesn't get deployed. How is that different from the bridge that doesn't get built or falls over? All the same factors are at play: poor planning, insufficient resources, bad management, inexperienced workers, insufficient funding, lack of testing. Plenty of construction projects have corners cut. Just like with software, it is someone's job to patch it later.