3 ms·

I don’t wholesale agree with the writing but it does mention working with someone who worked on the project and can share the theory. In that case, a new dev is

I don’t wholesale agree with the writing but it does mention working with someone who worked on the project and can share the theory. In that case, a new dev is hired, and you instill all the knowledge of the system in the new dev. Once you’ve trained them enough, you can move on. New devs will adapt and create new theory and solutions. Rinse and repeat.

majormajor 4y ago
That's that "second gen" vs "first gen" thing but it actually leans in hard to the "no movement" right after introducing that concept - the "Each team needs to be composed of a majority of first-generation developers" quote is from that paragraph after the distinction. If you try to fix the theory knowledge/documentation/practice problems purely through insisting the "first gen" stays where they are, they're going to leave you for more interesting work, and then you're in exactly the situation you wanted to avoid. The only way out is "more effective practice of theory and knowledge transfer" but all the author seems to have to say about that is "This is a team management issue that can only be addressed by a manager who understands the fundamental nature of software development. There is no magic development process that will prevent these problems. It takes skill." E.g. that's the real hard part yet they completely punt on trying to dig into it.
MarkMarine 4y ago
That kind of misses what is being said in this article. The first generation programmers support a constrained population of second generation developers, and over time the second generation developers have written enough code that they become the first generation. A big component of what this article is saying is basically that knowledge transfer in the way you're describing doesn't work, and if you dig down to the theory this article is based on, new devs adapt and create their own theory and solutions was specifically called out as a problem. In case 1 of this paper, it's described as second generation programmers submitting patches to the first generation programmers that don't make use of the structure of the program, and add things that are trivially done by the existing systems. Then, a third, disconnected generation of programmers takes over the maintenance from the second generation, and they've added so much cruft to the system that the original powerful architecture can still be seen, but isn't in use because of all the additions. [0] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- vosper 4y ago
  > A big component of what this article is saying is basically that knowledge transfer in the way you're describing doesn't work Knowledge transfer doesn't work at all :) It's not a thing that's possible. The best we can do is for someone with knowledge to attempt to explain it, hope they do a good and complete job of it, and then hope that the explainee is able to internalise it and come to the same/similar conceptual understanding that the explainer had in their mind. It doesn't tend to be done very well at corporations. It's a skill that good teachers have developed after much practice, which isn't something we tend to hire for. And it requires favourable conditions, and one of those conditions is not "it's my last day tomorrow and the boss asked me to bring you up to speed on what I've been doing these last six months. You only had 30 minutes free in your calendar, so... let's go"
  - MarkMarine 4y ago
    In the underlying theory it's described as actually worse than that. A fully documented system explained by the first generation developers wasn't enough to transfer knowledge, the documentation only made a difference once the programmers had built a working mental model of how the software worked, and then they still submitted patches that would duplicate functionality because they didn't understand the system.
    - majormajor 4y ago
      But this doesn't boil down to "you have to replace the impossible problem of knowledge transfer with infinite employee retention"? Is that an improvement? (I'd also argue that I've worked on systems where I've developed a better mental model of the problem than the first-gen people I inherited it from, because I as a maintainer was under less pressure to get anything that worked out the door initially.) EDIT: and looking at the paper you linked there, https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf , I'm in complete agreement with "the designer's job is not to pass along "the design" but to pass along "the theories" driving the design" - it was always easier as that maintainer to take over a project where people could tell my why not just what.

majormajor 4y ago

That's that "second gen" vs "first gen" thing but it actually leans in hard to the "no movement" right after introducing that concept - the "Each team needs to be composed of a majority of first-generation developers" quote is from that paragraph after the distinction. If you try to fix the theory knowledge/documentation/practice problems purely through insisting the "first gen" stays where they are, they're going to leave you for more interesting work, and then you're in exactly the situation you wanted to avoid. The only way out is "more effective practice of theory and knowledge transfer" but all the author seems to have to say about that is "This is a team management issue that can only be addressed by a manager who understands the fundamental nature of software development. There is no magic development process that will prevent these problems. It takes skill." E.g. that's the real hard part yet they completely punt on trying to dig into it.

MarkMarine 4y ago

That kind of misses what is being said in this article. The first generation programmers support a constrained population of second generation developers, and over time the second generation developers have written enough code that they become the first generation. A big component of what this article is saying is basically that knowledge transfer in the way you're describing doesn't work, and if you dig down to the theory this article is based on, new devs adapt and create their own theory and solutions was specifically called out as a problem. In case 1 of this paper, it's described as second generation programmers submitting patches to the first generation programmers that don't make use of the structure of the program, and add things that are trivially done by the existing systems. Then, a third, disconnected generation of programmers takes over the maintenance from the second generation, and they've added so much cruft to the system that the original powerful architecture can still be seen, but isn't in use because of all the additions. [0] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf

vosper 4y ago
> A big component of what this article is saying is basically that knowledge transfer in the way you're describing doesn't work Knowledge transfer doesn't work at all :) It's not a thing that's possible. The best we can do is for someone with knowledge to attempt to explain it, hope they do a good and complete job of it, and then hope that the explainee is able to internalise it and come to the same/similar conceptual understanding that the explainer had in their mind. It doesn't tend to be done very well at corporations. It's a skill that good teachers have developed after much practice, which isn't something we tend to hire for. And it requires favourable conditions, and one of those conditions is not "it's my last day tomorrow and the boss asked me to bring you up to speed on what I've been doing these last six months. You only had 30 minutes free in your calendar, so... let's go"
- MarkMarine 4y ago
  In the underlying theory it's described as actually worse than that. A fully documented system explained by the first generation developers wasn't enough to transfer knowledge, the documentation only made a difference once the programmers had built a working mental model of how the software worked, and then they still submitted patches that would duplicate functionality because they didn't understand the system.
  - majormajor 4y ago
    But this doesn't boil down to "you have to replace the impossible problem of knowledge transfer with infinite employee retention"? Is that an improvement? (I'd also argue that I've worked on systems where I've developed a better mental model of the problem than the first-gen people I inherited it from, because I as a maintainer was under less pressure to get anything that worked out the door initially.) EDIT: and looking at the paper you linked there, https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf , I'm in complete agreement with "the designer's job is not to pass along "the design" but to pass along "the theories" driving the design" - it was always easier as that maintainer to take over a project where people could tell my why not just what.