4 ms·

> 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

by 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.
  - BlueTemplar 4y ago
    Yeah, I was going to comment something like this : on a complex project even "first-generation" developers start out something more like """third-generation""" : after all the goal is to solve some problem, and the clients themselves might not even actually know what it is !
- mr_toad 4y ago
  > they still submitted patches that would duplicate functionality because they didn't understand the system. A lot of the time they don’t want to understand the system. Maintaining some old legacy system is no fun. Programmers want to do new things their own way. And if there’s no one around to guide them then they will. This is a management and cultural problem. Enterprise software resembles failed open source projects - no one wants to work on them so they die, get forked, or re-written and replaced. Contrast this with successful open source projects. A vibrant project will integrate new developers into the culture (or show them the door), and conversely developers who want to change things will have to prove themselves.
  - MarkMarine 4y ago
    The Naur paper seems to take as fact that even if motivated to learn, taught by the authors, and given good documentation… new developers just don’t pick up a complex system. The paper used a compiler for some language Y onto a target system X as an example. Personally, I don’t our ability to learn is that bad. Given time to come up to speed and motivation to read the code and understand it, and some good (consistent) coaching from people who fully understand the code, I believe new developers can be integrated into a complex codebase that they haven’t written. But this really draws a stark relief from the way software engineering on existing code is treated by every manager I’ve ever met, which is likened to reading a book once in a language you already know. One read through is enough to grok it. If we land somewhere closer to this source material on the spectrum I think that’s a win. I also look at my own thoughts on existing code. I’ve had the strong urge to refactor out old code I didn’t like… and that is interesting to me. Did I not like the style or just not understand it and want to make my own mental model my way? The idea that we’re just replacing engineers and they are just re-writing the same code with the same outcomes because we think of them as Lego blocks is interesting as well.

by vosper 4y ago

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.
- BlueTemplar 4y ago
  Yeah, I was going to comment something like this : on a complex project even "first-generation" developers start out something more like """third-generation""" : after all the goal is to solve some problem, and the clients themselves might not even actually know what it is !
mr_toad 4y ago
> they still submitted patches that would duplicate functionality because they didn't understand the system. A lot of the time they don’t want to understand the system. Maintaining some old legacy system is no fun. Programmers want to do new things their own way. And if there’s no one around to guide them then they will. This is a management and cultural problem. Enterprise software resembles failed open source projects - no one wants to work on them so they die, get forked, or re-written and replaced. Contrast this with successful open source projects. A vibrant project will integrate new developers into the culture (or show them the door), and conversely developers who want to change things will have to prove themselves.
- MarkMarine 4y ago
  The Naur paper seems to take as fact that even if motivated to learn, taught by the authors, and given good documentation… new developers just don’t pick up a complex system. The paper used a compiler for some language Y onto a target system X as an example. Personally, I don’t our ability to learn is that bad. Given time to come up to speed and motivation to read the code and understand it, and some good (consistent) coaching from people who fully understand the code, I believe new developers can be integrated into a complex codebase that they haven’t written. But this really draws a stark relief from the way software engineering on existing code is treated by every manager I’ve ever met, which is likened to reading a book once in a language you already know. One read through is enough to grok it. If we land somewhere closer to this source material on the spectrum I think that’s a win. I also look at my own thoughts on existing code. I’ve had the strong urge to refactor out old code I didn’t like… and that is interesting to me. Did I not like the style or just not understand it and want to make my own mental model my way? The idea that we’re just replacing engineers and they are just re-writing the same code with the same outcomes because we think of them as Lego blocks is interesting as well.