4 ms·

Restaurant industry version: I was so afraid to cook in a dirty kitchen, I ended up not cooking at all. This thread made me realize that's better to s

Restaurant industry version: I was so afraid to cook in a dirty kitchen, I ended up not cooking at all. This thread made me realize that's better to sell food prepared on dirty surfaces with unrefrigerated ingredientes half-eaten by rodents and roaches that makes people sick, than fresh food prepared on clean surfaces with clean utensils. I'm glad I read this. This is a restaurant worker story. Construction industry version: I was so afraid of not using the right construction materials and not building code-compliant structures, I ended up not building at all. This thread made me realize that's better to sell houses with structural problems and low quality materials that will be unsafe to live in, than houses built according to code. I'm glad I read this. This is a builder story. In any other industry, a person would go to jail for saying that. You won't, because luckily for you, software development is not a regulated activity, and people with your mindset can make a happy living outside of jail. But hopefully one day some types of neglect in software development become illegal. "Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with.

passivate 5y ago
Your analogy is flawed. The CPU doesn't care at all about how or what code looks like, all the nice comments explaining what it does, nice naming conventions, whether its easy to understand or not. They have zero impact on the final compiled code. The executable ends up as a spaghetti of machine instructions with countless gotos in a single large file. Using bad ingredients in food, or poor quality materials in construction has tremendous impact on the final product. >"Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with. Just calling code good or bad doesn't mean much - ultimately, results matter - if your code doesn't have tons of bugs, if your team can add features without any problems, if you can ship reasonably on time, if your product delivers value to the end user, etc - then you have succeeded. It doesn't matter what outsiders think about the code or what labels people give. Its best to ignore them and continue doing good work.
- 29athrowaway 5y ago
  - passivate 5y ago
    Why do you think you can pressure me into accepting your opinions? I don't want to argue with you so how about this - you do it your way and I'll do it my way. But, thanks for your concern.
patmcc 5y ago
If you're writing code that controls radiation therapy machines or trains or autoclaves or something, yah, maybe there should be some regulation and potential jail time for negligence. But 95% of all software written (especially if it's the first version of new software) isn't life or death. If the next social media startup or saas-for-painters is spaghetti code it's not going to hurt anyone. Failure is cheap in our industry. That's largely a very good thing.
- deleted 5y ago
  [deleted]
ByteJockey 5y ago
I think your examples are unfair. Getting stuck on needing the perfect architecture is closer to scrapping a building plan because it wouldn't hold up to a 2km asteroid strike than it is building something that will ultimately kill people. Also all of your examples have wildly different impacts than a dev "portfolio project". They all cause physical harm to people, which a poorly coded website/cli tool/etc almost certainly won't. Unless this person's hobby is writing code for MRI machines, in which case, go ahead and make everything is perfect, but that doesn't seem to be the case here.
- 29athrowaway 5y ago
  Basic hygiene when cooking is not perfectionism, and is not only done at elite restaurants. Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering.
  - ByteJockey 5y ago
    > Basic hygiene when cooking is not perfectionism, and is not only done at elite restaurants. Ok, so let's continue this analogy on the other one. It's less like basic hygiene, and more like refusing to cook outside a clean room. > Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering. Basic development good practices are something you develop during the "portfolio building phase", not before.
Mawr 5y ago
There's being uncharitable and then there's this. Your entire point rests on a baseless assumption. There's absolutely nothing in the parent's post that indicates that the programs he would create could have the potential to harm humans.
Zababa 5y ago
No, that is not the restaurant industry version or the construction industry version. You can't possibly compare "good practices" in software with building codes and food safety regulations. Building codes and food safety regulations are based on facts, science, and decades of experiences. Good practices are rooted in ideology, hype, and not based on facts. There are no studies showing that "having tests helps". There are no studies showing that "splitting code into multiple files means that you'll have a better end product". And experienced people (like in this thread) even say that there is often not that much correlation between how code "looks" and how well it works.
- 29athrowaway 5y ago
  > Good practices are rooted in ideology, hype, and not based on facts. That is a really sad statement that is predicated on the assumption that nothing can be objectively compared and therefore nothing can be ranked, which is also a way to kill arguments that lead to innovation and iterative improvement. You can measure the complexity of an algorithm, you can measure the cyclomatic complexity of a function, you can measure code in terms of length, you can count references to external functions or modules, etc. There are many ways in which you can compare code and make decisions about what style is more convenient for your team. What is clearer for you to understand? a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 b) 12 If your argument was true, they would both be the same. We both know that a) is a waste of time.
  - Zababa 5y ago
    Your example is oversimplifying the problem, I don't think you're proving anything here. I've used tools that calculate cyclomatic complexity, and sometimes they're a good indicator, and sometimes they aren't at all. You can measure the complexity of an algorithm, sure, but unless it comes with a real life benchmark, it's only part of the answer. Same with the length of the code, you can measure the length but it doesn't tell you much about how hard to follow is the code. If you take any style guide, book about good practice, or stuff like that, you'll find that there are some good ideas, and there are some bad ideas. Even with something as simple as code formatting, we still don't know as an industry if it's better to format everything the same, or use formatting to convey information. The debates about OO, FP, static/dynamic typing are endless and there's no evidence about which is better. There is a rough idea that you need more organization when more people work on code (static types, microservices, more documentation, more isolated parts), but even that isn't really clear. My assumption is not that "nothing can be objectively compared and therefore nothing can be ranked". It's not even an assumption, it's what I've seen in this industry: we lack data to give objective good practice that go beyond anything trivial ("try to make code easy to read and simple", "give meaningful names to your variables"). There is a wide gap between "common sense" and "cargo cults", which is the gap between easy and complex topics. I would really like if in the last 50 years we had learn a lot about how to build software as an industry, as people. The reality is that we haven't.

passivate 5y ago

Your analogy is flawed. The CPU doesn't care at all about how or what code looks like, all the nice comments explaining what it does, nice naming conventions, whether its easy to understand or not. They have zero impact on the final compiled code. The executable ends up as a spaghetti of machine instructions with countless gotos in a single large file. Using bad ingredients in food, or poor quality materials in construction has tremendous impact on the final product. >"Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with. Just calling code good or bad doesn't mean much - ultimately, results matter - if your code doesn't have tons of bugs, if your team can add features without any problems, if you can ship reasonably on time, if your product delivers value to the end user, etc - then you have succeeded. It doesn't matter what outsiders think about the code or what labels people give. Its best to ignore them and continue doing good work.

29athrowaway 5y ago
- passivate 5y ago
  Why do you think you can pressure me into accepting your opinions? I don't want to argue with you so how about this - you do it your way and I'll do it my way. But, thanks for your concern.

patmcc 5y ago

If you're writing code that controls radiation therapy machines or trains or autoclaves or something, yah, maybe there should be some regulation and potential jail time for negligence. But 95% of all software written (especially if it's the first version of new software) isn't life or death. If the next social media startup or saas-for-painters is spaghetti code it's not going to hurt anyone. Failure is cheap in our industry. That's largely a very good thing.

deleted 5y ago
[deleted]

ByteJockey 5y ago

I think your examples are unfair. Getting stuck on needing the perfect architecture is closer to scrapping a building plan because it wouldn't hold up to a 2km asteroid strike than it is building something that will ultimately kill people. Also all of your examples have wildly different impacts than a dev "portfolio project". They all cause physical harm to people, which a poorly coded website/cli tool/etc almost certainly won't. Unless this person's hobby is writing code for MRI machines, in which case, go ahead and make everything is perfect, but that doesn't seem to be the case here.

29athrowaway 5y ago
Basic hygiene when cooking is not perfectionism, and is not only done at elite restaurants. Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering.
- ByteJockey 5y ago
  > Basic hygiene when cooking is not perfectionism, and is not only done at elite restaurants. Ok, so let's continue this analogy on the other one. It's less like basic hygiene, and more like refusing to cook outside a clean room. > Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering. Basic development good practices are something you develop during the "portfolio building phase", not before.

Mawr 5y ago

There's being uncharitable and then there's this. Your entire point rests on a baseless assumption. There's absolutely nothing in the parent's post that indicates that the programs he would create could have the potential to harm humans.

Zababa 5y ago

No, that is not the restaurant industry version or the construction industry version. You can't possibly compare "good practices" in software with building codes and food safety regulations. Building codes and food safety regulations are based on facts, science, and decades of experiences. Good practices are rooted in ideology, hype, and not based on facts. There are no studies showing that "having tests helps". There are no studies showing that "splitting code into multiple files means that you'll have a better end product". And experienced people (like in this thread) even say that there is often not that much correlation between how code "looks" and how well it works.

29athrowaway 5y ago
> Good practices are rooted in ideology, hype, and not based on facts. That is a really sad statement that is predicated on the assumption that nothing can be objectively compared and therefore nothing can be ranked, which is also a way to kill arguments that lead to innovation and iterative improvement. You can measure the complexity of an algorithm, you can measure the cyclomatic complexity of a function, you can measure code in terms of length, you can count references to external functions or modules, etc. There are many ways in which you can compare code and make decisions about what style is more convenient for your team. What is clearer for you to understand? a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 b) 12 If your argument was true, they would both be the same. We both know that a) is a waste of time.
- Zababa 5y ago
  Your example is oversimplifying the problem, I don't think you're proving anything here. I've used tools that calculate cyclomatic complexity, and sometimes they're a good indicator, and sometimes they aren't at all. You can measure the complexity of an algorithm, sure, but unless it comes with a real life benchmark, it's only part of the answer. Same with the length of the code, you can measure the length but it doesn't tell you much about how hard to follow is the code. If you take any style guide, book about good practice, or stuff like that, you'll find that there are some good ideas, and there are some bad ideas. Even with something as simple as code formatting, we still don't know as an industry if it's better to format everything the same, or use formatting to convey information. The debates about OO, FP, static/dynamic typing are endless and there's no evidence about which is better. There is a rough idea that you need more organization when more people work on code (static types, microservices, more documentation, more isolated parts), but even that isn't really clear. My assumption is not that "nothing can be objectively compared and therefore nothing can be ranked". It's not even an assumption, it's what I've seen in this industry: we lack data to give objective good practice that go beyond anything trivial ("try to make code easy to read and simple", "give meaningful names to your variables"). There is a wide gap between "common sense" and "cargo cults", which is the gap between easy and complex topics. I would really like if in the last 50 years we had learn a lot about how to build software as an industry, as people. The reality is that we haven't.