Hacker News Reader

Comment by hinkley | Hacker News Reader

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.

View on HN

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

> 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.

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.

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)

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.

In my experience (and I generally have found myself in the position of 'person that has the system in their head'), it's not necessarily about size but about being able to sit down and work with the system. It's not just about having the theory but also having the time actually working with the system and learning how things act in practice, which is a kinda weird mix between being a senior role with a high-level view of the system and a theoretically quite junior role of more or less technician.

(It also usually involves some quite proactive learning of the form of finding the specialist in some part of the system and sitting next to them and going "explain to me how this part works", and then repeating more or less indefinitely)

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.

> 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.

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.

That sounds like a very interesting theory, with an actionable result. Do you have any links for more reading?

I haven’t talked to that guy in a while. The way the class was described I expect there’s a bibliography somewhere though.

Reply on news.ycombinator.com