4 ms·

This is eerily similar to the comment on the thread about LLMs that says software teams have to maintain a "theory" or model about how the software works and wh

This is eerily similar to the comment on the thread about LLMs that says software teams have to maintain a "theory" or model about how the software works and when they cant, they can no longer function beyond limited forms of maintenance. And in that comment the idea was that LLMs are accelerating this dynamic. I dont want to stretch the analogy too thin but in this case instead of LLMs being a catalyst, perhaps its a monopoly.

hinkley 1y ago
Rensselaer Polytechnic Institute Has a degree that’s basically informatics management. My coworker took a class with case studies and the theory presented by that class was that all successful projects have at least one person who has fit the entire system into their head. They can tell you what happens if you pull on this thread. What the consequences are of trying to remove this feature. Lose them and you are fucked. Until or unless someone else steps up and does the same. If they can’t it’s the beginning of the end.
- cptroot 1y ago
  That sounds like a very interesting theory, with an actionable result. Do you have any links for more reading?
  - hinkley 1y ago
    I haven’t talked to that guy in a while. The way the class was described I expect there’s a bibliography somewhere though.
- procaryote 1y ago
  For software, the easiest way to design for this is to keep systems small enough that fitting it in your head is relatively feasible in a reasonable time for a competent engineer. Connect them with clear APIs that don't have to change all that often, and you can build pretty big things. I imagine this is doable with hardware too
  - unreal6 1y ago
    > Connect them with clear APIs that don't have to change all that often, and you can build pretty big things. Emphasis on clear. It's a challenging endeavor to properly draw and enforce these service boundaries.
    - hinkley 1y ago
      Occasionally I make an analogy to stage acting or opera. In order for the people in the medium priced seats to see the action on the stage, all the actors have to over-emote to make everything that is happening dreadfully obvious. In a system that is the composition of 30-300 different functional units, nobody will be close to any one part unless they’re the bus number for it. So each piece needs to be dead obvious so you can worry about the consequences of composing them. At the end of the day it’s Kernighan’s Law but rephrased so as not to ignore Conway or Brooks.
    - procaryote 1y ago
      Definitely! My metric is "how often do I need to change two systems at once". This is one of the things monorepos help in some ways (by making it easier to change two systems) and break in some ways (as you now get less annoyed by the split between systems being in the wrong place)
  - hinkley 1y ago
    My yard stick is discoverability. If you don’t touch things for a while they get fuzzy, and someone might have refactored it. So you need to be able to familiarize yourself with bits of the code you haven’t looked at recently. Helps with code reviews, onboarding, and production outages. In particular it’s difficult to train new people to take up on-call duties if they cannot sit in the corner of the room and try either the same things you’re trying or their own pet theories without taking your attention or interfering with your tests. They need to be able to hear the repro steps and spool up their own snapshot in a similar state. That scales. Gatekeepers do not. Discoverability is necessary but insufficient to achieve this. There’s more to it but the foundation is discoverability and reproduceability.
  - rcxdude 1y ago
- magicalhippo 1y ago
  I've been on large projects where we didn't have one such person but was nevertheless very successful. The key there was that one qualified representative for each part of the affected organization and other relevant parties in the core team, and there were frequent alignment meetings where they were all present. The representatives were close to the action, not some three-levels-removed manager. In the meetings processes and such would get discussed step by step in detail, and any representative could chime in at any point to say "this won't work" or similar. Hard to do though, and quite costly in terms of organizational resources required.
- lelanthran 1y ago
  > Until or unless someone else steps up and does the same. Or the company ponies up and rewrites the thing. Sometimes legacy really is bad, and sometimes you really do need to throw the old product into the bin. See Trello for an example.
  - hinkley 1y ago
    Rewriting is moving the goalposts and hoping that person emerges in the rewrite. They often don’t. Or they get fed up with reasonable criticism and leave. Which is a variant of the Lavaflow Antipattern.
uh_uh 1y ago
> This is eerily similar to the comment on the thread about LLMs that says software teams have to maintain a "theory" or model about how the software works and when they cant, they can no longer function beyond limited forms of maintenance. Link: https://news.ycombinator.com/item?id=45424366 https://news.ycombinator.com/item?id=45424366

hinkley 1y ago

Rensselaer Polytechnic Institute Has a degree that’s basically informatics management. My coworker took a class with case studies and the theory presented by that class was that all successful projects have at least one person who has fit the entire system into their head. They can tell you what happens if you pull on this thread. What the consequences are of trying to remove this feature. Lose them and you are fucked. Until or unless someone else steps up and does the same. If they can’t it’s the beginning of the end.

cptroot 1y ago
That sounds like a very interesting theory, with an actionable result. Do you have any links for more reading?
- hinkley 1y ago
  I haven’t talked to that guy in a while. The way the class was described I expect there’s a bibliography somewhere though.
procaryote 1y ago
For software, the easiest way to design for this is to keep systems small enough that fitting it in your head is relatively feasible in a reasonable time for a competent engineer. Connect them with clear APIs that don't have to change all that often, and you can build pretty big things. I imagine this is doable with hardware too
- unreal6 1y ago
  > Connect them with clear APIs that don't have to change all that often, and you can build pretty big things. Emphasis on clear. It's a challenging endeavor to properly draw and enforce these service boundaries.
  - hinkley 1y ago
    Occasionally I make an analogy to stage acting or opera. In order for the people in the medium priced seats to see the action on the stage, all the actors have to over-emote to make everything that is happening dreadfully obvious. In a system that is the composition of 30-300 different functional units, nobody will be close to any one part unless they’re the bus number for it. So each piece needs to be dead obvious so you can worry about the consequences of composing them. At the end of the day it’s Kernighan’s Law but rephrased so as not to ignore Conway or Brooks.
  - procaryote 1y ago
    Definitely! My metric is "how often do I need to change two systems at once". This is one of the things monorepos help in some ways (by making it easier to change two systems) and break in some ways (as you now get less annoyed by the split between systems being in the wrong place)
- hinkley 1y ago
  My yard stick is discoverability. If you don’t touch things for a while they get fuzzy, and someone might have refactored it. So you need to be able to familiarize yourself with bits of the code you haven’t looked at recently. Helps with code reviews, onboarding, and production outages. In particular it’s difficult to train new people to take up on-call duties if they cannot sit in the corner of the room and try either the same things you’re trying or their own pet theories without taking your attention or interfering with your tests. They need to be able to hear the repro steps and spool up their own snapshot in a similar state. That scales. Gatekeepers do not. Discoverability is necessary but insufficient to achieve this. There’s more to it but the foundation is discoverability and reproduceability.
- rcxdude 1y ago
magicalhippo 1y ago
I've been on large projects where we didn't have one such person but was nevertheless very successful. The key there was that one qualified representative for each part of the affected organization and other relevant parties in the core team, and there were frequent alignment meetings where they were all present. The representatives were close to the action, not some three-levels-removed manager. In the meetings processes and such would get discussed step by step in detail, and any representative could chime in at any point to say "this won't work" or similar. Hard to do though, and quite costly in terms of organizational resources required.
lelanthran 1y ago
> Until or unless someone else steps up and does the same. Or the company ponies up and rewrites the thing. Sometimes legacy really is bad, and sometimes you really do need to throw the old product into the bin. See Trello for an example.
- hinkley 1y ago
  Rewriting is moving the goalposts and hoping that person emerges in the rewrite. They often don’t. Or they get fed up with reasonable criticism and leave. Which is a variant of the Lavaflow Antipattern.

uh_uh 1y ago

> This is eerily similar to the comment on the thread about LLMs that says software teams have to maintain a "theory" or model about how the software works and when they cant, they can no longer function beyond limited forms of maintenance. Link: https://news.ycombinator.com/item?id=45424366 https://news.ycombinator.com/item?id=45424366