[zahlman]

> Idk, while system architecture diagrams look cool and feel informative, I generally don't feel like they actually help you get started working somewhere on a project.

My reaction to the title was that trying to create the diagram is the mistake. If you can't explain it in prose, simplify.

[dpark]

A picture’s worth a thousand words.

A diagram is a dense way to express information. The same information in prose would take much longer for a typical human to absorb.

> If you can't explain it in prose, simplify.

Simplify what? The system? Usually you can’t just throw things away from the system to make it easier to describe.

[vanviegen]

> A diagram is a dense way to express information.

I'd say it's a lossy way to express information. I find that architecture diagrams often cannot express the exact concepts I mean to communicate, so you're left trying to shoehorn concepts into boxes that are somewhat similar, and try to make up for the difference using a couple of cryptic words.

Prose doesn't look as nice, but allows me to describe exactly what I want to say, on any level of detail required. Of course, like with a diagram, you do need to put in significant time and effort to make it comprehensible.

[dpark]

> I'd say it's a lossy way to express information.

A simplified explanation of the system is by definition lossy. This equally applies to a plain English description.

I’ve been in many design reviews and similar forums where someone has attempted to present a design through written English and finally someone says “we need a diagram here; this is too much to follow” and everyone in the audience nods because they are all lost.

One of the problems with trying to communicate system design with prose is that it makes sense to the person who writes it and has full context, but the audience is often left confused. Diagrams are often easier to follow specifically because they look under specified when they are.

[vanviegen]

> finally someone says “we need a diagram here; this is too much to follow” and everyone in the audience nods because they are all lost.

Yes, that happens. I can't remember any occasions where the diagram actually cleared things up though.

Coming to think of it, one way that seems to be pretty effective at getting complex designs across is in an interactive presentation with the presenter drawing on a whiteboard, starting simple and adding stuff while explaining what and why. The narrative is very important though. The whiteboard drawings by themselves are absolutely useless.

[dpark]

> I can't remember any occasions where the diagram actually cleared things up though.

I would be very concerned about the quality of the engineers I was working with if they couldn’t produce helpful diagrams.

It’s not coincidental that discussion of system architecture is usually accompanied by diagrams. They should be helpful. And in fact…

> Coming to think of it, one way that seems to be pretty effective at getting complex designs across is in an interactive presentation with the presenter drawing on a whiteboard, starting simple and adding stuff while explaining what and why.

You seem to agree that they are helpful.

> The whiteboard drawings by themselves are absolutely useless.

This seems like sort of a straw man, though. I don’t think anyone advocates for system diagrams in the absence of any context.

[vanviegen]

> This seems like sort of a straw man, though. I don’t think anyone advocates for system diagrams in the absence of any context.

My point is that I see value in interactively building up a diagram together. The final artifact, even when provided with context in the form of prose, I've never found to be actually helpful. Apart from good looks of course.

[zahlman]

> Usually you can’t just throw things away from the system to make it easier to describe.

You can't throw away requirements, but sometimes there don't need to be as many moving parts behind the curtain as you think in order to implement those requirements.

[dpark]

This is essentially a statement that the system shouldn’t be unnecessarily complex. And sure, but that’s not really relevant to the discussion.

If you have a complex system, whether due to legacy or due to actual necessity, you aren’t going to redesign the system just for the sake of simpler explanation. Indeed if someone couldn’t explain the system in its current state I would have zero confidence they could successfully simplify it.

[zahlman]

My point was that the attitude of being able to explain systems by drawing them, leads to over-architecting them. If you stick to prose then you can't as easily delude yourself about the complexity by staring at pretty pictures.

I was not considering the case of documenting already existing systems, just talking about the planning stage. Your point is well taken.

[stronglikedan]

Some stakeholders will gain more understanding from a diagram than any amount of simplified prose, so both are typically helpful.