4 ms·

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 tra

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.

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.