The parent's point (and one which I agree with) is that the PowerPoint is not the vehicle for details. It's the vehicle for strategy and framing.
Let's take an example. A customer wants to expose my employer's application to external partners / customers / whatever and they need guidance on how to do this. There are a few models on how to do this with positives and negatives:
1. Place a server in a DMZ
2. Reverse Proxy traffic in
3. Have a separate site in a DMZ and programmatically push content there
Sure, I could get on a call and verbally describe those options. But it's infinitely easier to put up a few architecture diagrams which visually depict the options with call outs to considerations with each.
It's fair to ask why can't this be documented in a technical brief / whitepaper / documentation. Well, it is, at least mostly. It's out there. We send links to plenty of documentation. What documentation is extraordinarily bad at is explaining nuance. Best practices are fine, but best practices have a set of assumptions. Those assumptions may be generally true but are entirely simplistic at the margins.
Back to my example. Should we document how the interaction between the DoD's various network segments (think NIPR and SIPR)? Would it shock you that various groups inside of individual branches of the DoD interpret things differently? What about an organization where this use case is the first external exposure of internally deployed software?
Ultimately a good use of the PowerPoint medium is to reduce complexity to the essentials, allow for framing of the underlying issues, and to be used as a pivot to discuss broader strategy. No argument from me that many uses of PowerPoint are laughable. But there's a whole sphere of the technology realm which involve sales, sales adjacent, or strategic discussions where PowerPoint or similar techniques are essential when more formal documentation has not settled things.
Let's take an example. A customer wants to expose my employer's application to external partners / customers / whatever and they need guidance on how to do this. There are a few models on how to do this with positives and negatives:
1. Place a server in a DMZ 2. Reverse Proxy traffic in 3. Have a separate site in a DMZ and programmatically push content there
Sure, I could get on a call and verbally describe those options. But it's infinitely easier to put up a few architecture diagrams which visually depict the options with call outs to considerations with each.
It's fair to ask why can't this be documented in a technical brief / whitepaper / documentation. Well, it is, at least mostly. It's out there. We send links to plenty of documentation. What documentation is extraordinarily bad at is explaining nuance. Best practices are fine, but best practices have a set of assumptions. Those assumptions may be generally true but are entirely simplistic at the margins.
Back to my example. Should we document how the interaction between the DoD's various network segments (think NIPR and SIPR)? Would it shock you that various groups inside of individual branches of the DoD interpret things differently? What about an organization where this use case is the first external exposure of internally deployed software?
Ultimately a good use of the PowerPoint medium is to reduce complexity to the essentials, allow for framing of the underlying issues, and to be used as a pivot to discuss broader strategy. No argument from me that many uses of PowerPoint are laughable. But there's a whole sphere of the technology realm which involve sales, sales adjacent, or strategic discussions where PowerPoint or similar techniques are essential when more formal documentation has not settled things.