4 ms·

At which point, the real question is: why did they choose not to document this non-obvious solution, and the edge case that required it? From my personal exper

At which point, the real question is: why did they choose not to document this non-obvious solution, and the edge case that required it? From my personal experience with "corporate programming", the usual suspects are: 1) corporate culture that dictates that you need to get the code out ASAP and let someone else worry about maintenance 2) original author's assumption that he/she will be the only one to touch that code I've been guilty of #2 before I learned that even if I am the only one to touch the code, if I wait long enough before I come back to it, I'll still have the same problem as a newcomer would. As for #1, this is a typical corporate culture for any company whose business isn't producing code (and for quite a few whose business is precisely that).

nathan_long 14y ago
1) corporate culture that dictates that you need to get the code out ASAP and let someone else worry about maintenance Unfortunately, three months from now, "someone else" is you, and "getting the code out ASAP" means figuring out the spaghetti code you wrote but no longer understand. In the long run, doing it right the first time helps us go faster. Therefore, it's part of the programmer's job to resist pressure to do it wrong.
vidarh 14y ago
3) The code was indeed obvious for the people who had worked on the project for a while. When you get familiar with a domain it is very easy to get blind to what people without exposure to it will consider obvious or not.
pasbesoin 14y ago
3) A culture that thinks/mandates that "unnecessary comments" "clutter" the code. 4) Documentation that is held separate / made in different systems. That diverge over time. Or, one failure in training of the new guy is to not provide them a good overview of the documentation system(s). And/Or, the documentation organization and systems are cumbersome to the point of being unuseful, unless you already have a pretty good idea of where stuff is (and isn't -- all those empty forms that end up being ignored).
- wtracy 14y ago
  #4 has made my life miserable in the past, and will probably do so again. ISO certification requirements seem to exacerbate it, interestingly (frustratingly) enough.

nathan_long 14y ago

1) corporate culture that dictates that you need to get the code out ASAP and let someone else worry about maintenance Unfortunately, three months from now, "someone else" is you, and "getting the code out ASAP" means figuring out the spaghetti code you wrote but no longer understand. In the long run, doing it right the first time helps us go faster. Therefore, it's part of the programmer's job to resist pressure to do it wrong.

vidarh 14y ago

3) The code was indeed obvious for the people who had worked on the project for a while. When you get familiar with a domain it is very easy to get blind to what people without exposure to it will consider obvious or not.

pasbesoin 14y ago

3) A culture that thinks/mandates that "unnecessary comments" "clutter" the code. 4) Documentation that is held separate / made in different systems. That diverge over time. Or, one failure in training of the new guy is to not provide them a good overview of the documentation system(s). And/Or, the documentation organization and systems are cumbersome to the point of being unuseful, unless you already have a pretty good idea of where stuff is (and isn't -- all those empty forms that end up being ignored).

wtracy 14y ago
#4 has made my life miserable in the past, and will probably do so again. ISO certification requirements seem to exacerbate it, interestingly (frustratingly) enough.