5 ms·

The amount of broken code that exists in production seems to disagree with that first statement.

jeffreygoesto 4y ago
Why though? Most broken code I saw is due to not getting the requirements and edge cases right. Getting to know those is communkcation and wanting to know them is experience.
- dagss 4y ago
  I have seen lots of code where the author did not understand DB transactions (at all!), without idempotency even if it was critical, test suites that call getters and setters for coverage stats but without any actual assertions; those kind of things.
- end_of_line 4y ago
  Still you do have some requirements. Many legacy systems are 'as-is'. Just more or less working source code with huge label 'don't touch it'.
  - jeffreygoesto 4y ago
    True. Question is, what makes you succeed in that situation? Try to elicit why it became what it is or just run? ;)
    - end_of_line 4y ago
      Understanding that you don't really need to understand it all and you need to understand only part of them. If you do try otherwise, you run into overhours :-) Most popular technique to 'just do the thing' is using 'if my case do #1, else do #2'. Mostly because nobody really understand the business logic. Many reasons, no real one single document with spec, only wikipedia called confluence where you have half truths, barely truths and contradicting each other statements. In such situation you almost never will understand the logic because there are even no use cases and thus all you can get are regression tests (because there are no use cases list). It gets accumulated over years, many externals / consultants with half-life time 1 year and so continues - chaos in specs (sometimes even transfering from one tool to another one with losing info) and big rotation in companies too dependent on externals. So instead doing simple if-else, it's better to use wrapper / decorator or even better proxy of chain if more complicated. It all depends and this textbox is too short to explain the fun facts :-)
- ironmagma 4y ago
  I doubt anything someone writes here could change your mind. There are just so many things: knowing when to add tests, checking multiple places when fixing a bug, avoiding mutation, knowing when to do a rewrite, avoiding complexity… these are all things that are just knowing how to code that are difficult.
  - dahart 4y ago
    It was a valid question, no need to try to project hard-headedness. You probably won’t change any minds that way. So how do people come to know these things? Can you learn them in a vacuum sitting by yourself without communicating with anyone? Knowing when and how to add tests is a company-specific task, it’s different every place you’ll work, someone has to tell you. What if the primary reason code breaks really is because people weren’t communicating over the process, requirements, dependencies or design enough? All the things you mentioned are things a mentor and code reviews and documentation are meant to address, i.e., communication.
    - ironmagma 4y ago
      I think all these things can be learned even as a company of one, without ever speaking to your customers. It will take longer and the lessons will be harder to learn, but you will get all of it because it’s just problems with the programmer himself/herself, not problems with other people. We can “what if” all day.. and yes, mentoring can improve these things but that can be said about lots of things that aren’t caused by poor communication. It just really sounds like you need the answer to be poor communication which is why I reacted that way.
      - dahart 4y ago
        > It just really sounds like you need the answer to be poor communication which is why I reacted that way. Please. This is out of order. You didn’t react to me originally, and nobody here demanded that the answer is communication. You’re the only one insisting. You were asked a simple question, and the (as yet unanswered) question to you was why you attribute problems in production to coding and not communication, since there are plenty of examples of miscommunication leading to production bugs. This ad-hominem nonsense is you just making assumptions. I can easily agree that you’re sometimes right, that there are some bugs caused by lack of knowledge or skill or schooling, and that there are bugs caused by individuals and that communication plays little to no role. I can also safely say, after a career that spans about the same length as the article author’s, and after doing decades of both programming and management, that the majority of problems that matter in production and the biggest and worst problems I’ve seen were caused by poor communication. One example would be that I’ve twice watched engineering departments decide to rewrite a large codebase from scratch, and it turned into a many year effort costing many millions of dollars, with thousands of production bugs and issues all resulting from the decision that wasn’t well planned. There are of course also bugs that are both, caused by individual knowledge or skill, but could have been saved with more oversight. Feel free to share some concrete examples if you have some that you feel demonstrate production issues are cause more often by pure code and are not miscommunication. I’ve seen some and I have no doubt there are some. I’m open to hearing your answer and examples. Keep in mind this thread so far from my perspective is text-book miscommunication; the claim that production bugs means code is the cause and communication is not, is so broad and so vague and so ill-defined that of course I have no idea what you really mean. Feel free to elaborate and illustrate your point more clearly.
deleted 4y ago
[deleted]

Why though? Most broken code I saw is due to not getting the requirements and edge cases right. Getting to know those is communkcation and wanting to know them is experience.

dagss 4y ago
I have seen lots of code where the author did not understand DB transactions (at all!), without idempotency even if it was critical, test suites that call getters and setters for coverage stats but without any actual assertions; those kind of things.
end_of_line 4y ago
Still you do have some requirements. Many legacy systems are 'as-is'. Just more or less working source code with huge label 'don't touch it'.
- jeffreygoesto 4y ago
  True. Question is, what makes you succeed in that situation? Try to elicit why it became what it is or just run? ;)
  - end_of_line 4y ago
    Understanding that you don't really need to understand it all and you need to understand only part of them. If you do try otherwise, you run into overhours :-) Most popular technique to 'just do the thing' is using 'if my case do #1, else do #2'. Mostly because nobody really understand the business logic. Many reasons, no real one single document with spec, only wikipedia called confluence where you have half truths, barely truths and contradicting each other statements. In such situation you almost never will understand the logic because there are even no use cases and thus all you can get are regression tests (because there are no use cases list). It gets accumulated over years, many externals / consultants with half-life time 1 year and so continues - chaos in specs (sometimes even transfering from one tool to another one with losing info) and big rotation in companies too dependent on externals. So instead doing simple if-else, it's better to use wrapper / decorator or even better proxy of chain if more complicated. It all depends and this textbox is too short to explain the fun facts :-)
ironmagma 4y ago
I doubt anything someone writes here could change your mind. There are just so many things: knowing when to add tests, checking multiple places when fixing a bug, avoiding mutation, knowing when to do a rewrite, avoiding complexity… these are all things that are just knowing how to code that are difficult.
- dahart 4y ago
  It was a valid question, no need to try to project hard-headedness. You probably won’t change any minds that way. So how do people come to know these things? Can you learn them in a vacuum sitting by yourself without communicating with anyone? Knowing when and how to add tests is a company-specific task, it’s different every place you’ll work, someone has to tell you. What if the primary reason code breaks really is because people weren’t communicating over the process, requirements, dependencies or design enough? All the things you mentioned are things a mentor and code reviews and documentation are meant to address, i.e., communication.
  - ironmagma 4y ago
    I think all these things can be learned even as a company of one, without ever speaking to your customers. It will take longer and the lessons will be harder to learn, but you will get all of it because it’s just problems with the programmer himself/herself, not problems with other people. We can “what if” all day.. and yes, mentoring can improve these things but that can be said about lots of things that aren’t caused by poor communication. It just really sounds like you need the answer to be poor communication which is why I reacted that way.
    - dahart 4y ago
      > It just really sounds like you need the answer to be poor communication which is why I reacted that way. Please. This is out of order. You didn’t react to me originally, and nobody here demanded that the answer is communication. You’re the only one insisting. You were asked a simple question, and the (as yet unanswered) question to you was why you attribute problems in production to coding and not communication, since there are plenty of examples of miscommunication leading to production bugs. This ad-hominem nonsense is you just making assumptions. I can easily agree that you’re sometimes right, that there are some bugs caused by lack of knowledge or skill or schooling, and that there are bugs caused by individuals and that communication plays little to no role. I can also safely say, after a career that spans about the same length as the article author’s, and after doing decades of both programming and management, that the majority of problems that matter in production and the biggest and worst problems I’ve seen were caused by poor communication. One example would be that I’ve twice watched engineering departments decide to rewrite a large codebase from scratch, and it turned into a many year effort costing many millions of dollars, with thousands of production bugs and issues all resulting from the decision that wasn’t well planned. There are of course also bugs that are both, caused by individual knowledge or skill, but could have been saved with more oversight. Feel free to share some concrete examples if you have some that you feel demonstrate production issues are cause more often by pure code and are not miscommunication. I’ve seen some and I have no doubt there are some. I’m open to hearing your answer and examples. Keep in mind this thread so far from my perspective is text-book miscommunication; the claim that production bugs means code is the cause and communication is not, is so broad and so vague and so ill-defined that of course I have no idea what you really mean. Feel free to elaborate and illustrate your point more clearly.

deleted 4y ago

[deleted]