5 ms·

When talking about quality, "good enough" is always good enough. When I build a garden shed, I will not make strength calculations on the whole think, and my f

When talking about quality, "good enough" is always good enough. When I build a garden shed, I will not make strength calculations on the whole think, and my foundation will be pretty basic. My "timbered some wood together" shed will stand for 50 years, just as the "made a garden shed like an appartement building". Only the latter will take way more time and effort. When building an appartement building, good luck doing that with the same effort as building a shed. You will have some nasty surprises once you start adding weight to the different floors. The whole thing will collapse. So in the end, it makes no sense to build a garden shed as you would an appartement building, and it makes no sense to build an appartement building as a town shed. A lot of people forget this in the software world. So the quality "support" depends on the project itself. Small projects need less, big projects more. Just like small companies need less process overhead, and big companies more. Like everything in life, it all comes down to balance, and experience will teach you where the balance lies. Because sometimes you will go too far the the left, and after that you compensate and go too far to the right. But the balance will always be somewhere in the middle. So no matter what project, "good enough" will always be good enough.

lazulicurio 7y ago
> So in the end, it makes no sense to build a garden shed as you would an appartement building, and it makes no sense to build an apartment building as a town shed. A lot of people forget this in the software world. I agree, but I think that in the software world we're not even to the point where we can build sheds reliably well. We have neither historical knowledge that informs what the "ideal"[1] shed should look like, nor materials that won't suddenly change form the next day[2], nor tools that won't sometimes explode on us halfway through construction. I understand the disdain for the "sufficiently smart compiler" argument, but I think that there's a long way to go in development of software tooling before we can get to the point of slapping together software like a shed. A pet peeve currently on my mind is throwing exceptions for invalid method parameters. For example, I genuinely appreciate the work that Microsoft has been putting into the .Net ecosystem, but out of all the recent changes I feel like non-nullable references is the only one that helps me write higher quality code instead of improving productivity a little bit (Now we just need enums that are actually type safe (one can dream)). I'm excited for Rust, I hope it finds success in the world dominated by C/C++. I'm hoping something similar comes along for the world dominated by Java/C#. Elixr looks really cool and in the vein of what I would be wanting, but I haven't used it at all to know how an "enterprise" Elixr development process would work. I'm just hoping that "good enough" can get better in my lifetime. [1] Not in the quality sense, but in the "Platonic ideal" sense [2] Broken dependencies
jacques_chester 7y ago
> When talking about quality, "good enough" is always good enough. Humans are poor estimators of "good enough", due to a number of biases (optimism bias / planning fallacy, Dunning-Kreuger effect, hyperbolic discounting etc). This is partly why your reference industry, building construction, is so thoroughly covered by regulation and caselaw. Apartments would be much more frequently half-arsed if there weren't unpalatable legal and financial consequences for doing so.
agentultra 7y ago
See: Who Builds a Skyscraper without Drawing Blueprints? [0] I think we do have the tools to build Skyscrapers in software. I don't think it's as expensive as it used to be but it is certainly more expensive than it is now. The reason I think we've seen so much innovation in the last couple of decades in software is because we're getting away with building Skyscrapers with little, to no, regulation or oversight. Great for profits. Not so great for insurers, democracies, and regular people who have to deal with identity theft and fraud claims. Fortunately it's not like JPL in the 90s. Writing reliable, critical infrastructure doesn't cost nearly as much with the advance of automated model checking and interactive theorem proving tools. The skills to use those tools are more difficult to acquire than the ability to write a valid C program but I don't think every software developer will need to. If enough people in senior positions start insisting on their use I think we'll do well. In the meantime... when you need to know whether you're building a shed in a yard or a skyscraper you can look to your local professional engineering society for answers. In my area they have classifications available just as they would at your local city hall for determining if you need a permit to build your structure. [0] https://www.youtube.com/watch?v=iCRqE59VXT0 https://www.youtube.com/watch?v=iCRqE59VXT0 Update There's also a handy reference guide called, the Software Engineering Body of Knowledge or SWEBOK which is regularly updated with the current state of the art. It's quite useful to be familiar with it at least: https://www.computer.org/education/bodies-of-knowledge/software-engineering https://www.computer.org/education/bodies-of-knowledge/softw...
mountainofdeath 7y ago
The with "good enough" is when it's not applied correctly. Simple script to move files around? That's fine. Business critical software your firm produces but doesn't directly use? No. I've seen the latter case many times.

lazulicurio 7y ago

> So in the end, it makes no sense to build a garden shed as you would an appartement building, and it makes no sense to build an apartment building as a town shed. A lot of people forget this in the software world. I agree, but I think that in the software world we're not even to the point where we can build sheds reliably well. We have neither historical knowledge that informs what the "ideal"[1] shed should look like, nor materials that won't suddenly change form the next day[2], nor tools that won't sometimes explode on us halfway through construction. I understand the disdain for the "sufficiently smart compiler" argument, but I think that there's a long way to go in development of software tooling before we can get to the point of slapping together software like a shed. A pet peeve currently on my mind is throwing exceptions for invalid method parameters. For example, I genuinely appreciate the work that Microsoft has been putting into the .Net ecosystem, but out of all the recent changes I feel like non-nullable references is the only one that helps me write higher quality code instead of improving productivity a little bit (Now we just need enums that are actually type safe (one can dream)). I'm excited for Rust, I hope it finds success in the world dominated by C/C++. I'm hoping something similar comes along for the world dominated by Java/C#. Elixr looks really cool and in the vein of what I would be wanting, but I haven't used it at all to know how an "enterprise" Elixr development process would work. I'm just hoping that "good enough" can get better in my lifetime. [1] Not in the quality sense, but in the "Platonic ideal" sense [2] Broken dependencies

jacques_chester 7y ago

> When talking about quality, "good enough" is always good enough. Humans are poor estimators of "good enough", due to a number of biases (optimism bias / planning fallacy, Dunning-Kreuger effect, hyperbolic discounting etc). This is partly why your reference industry, building construction, is so thoroughly covered by regulation and caselaw. Apartments would be much more frequently half-arsed if there weren't unpalatable legal and financial consequences for doing so.

agentultra 7y ago

See: Who Builds a Skyscraper without Drawing Blueprints? [0] I think we do have the tools to build Skyscrapers in software. I don't think it's as expensive as it used to be but it is certainly more expensive than it is now. The reason I think we've seen so much innovation in the last couple of decades in software is because we're getting away with building Skyscrapers with little, to no, regulation or oversight. Great for profits. Not so great for insurers, democracies, and regular people who have to deal with identity theft and fraud claims. Fortunately it's not like JPL in the 90s. Writing reliable, critical infrastructure doesn't cost nearly as much with the advance of automated model checking and interactive theorem proving tools. The skills to use those tools are more difficult to acquire than the ability to write a valid C program but I don't think every software developer will need to. If enough people in senior positions start insisting on their use I think we'll do well. In the meantime... when you need to know whether you're building a shed in a yard or a skyscraper you can look to your local professional engineering society for answers. In my area they have classifications available just as they would at your local city hall for determining if you need a permit to build your structure. [0] https://www.youtube.com/watch?v=iCRqE59VXT0 https://www.youtube.com/watch?v=iCRqE59VXT0 Update There's also a handy reference guide called, the Software Engineering Body of Knowledge or SWEBOK which is regularly updated with the current state of the art. It's quite useful to be familiar with it at least: https://www.computer.org/education/bodies-of-knowledge/software-engineering https://www.computer.org/education/bodies-of-knowledge/softw...

mountainofdeath 7y ago

The with "good enough" is when it's not applied correctly. Simple script to move files around? That's fine. Business critical software your firm produces but doesn't directly use? No. I've seen the latter case many times.