Honestly, I think a pretty good pyramid scheme a la the Mikkelson Twins would be to start up a wholly imaginary "MIL-SPEC SCAMMER SCHOOL" that tells you all about people like this lady, and offers a course on HOW TO NOT DO SUCH BAD THINGS, while winking with every muscle in your body.

Or, even better, advise you on how to be a big time MIL-SPEC guru who can lead SIGMA or whatever other nonsense the management of the day is huffing. This advise is your key to landing BIG WORK in the Defense Industry! Everyone knows it's all nonsense, but we can teach you how to turn that nonsense into passive income.

Of course such a fabulous class would cost beaucoup buxxx....

Ah, this sounds heartbreaking. I'll leave it to those salesmen with mental sickness.

I'm reminded of how you have to use `{empty}` character refs in lightweight markup like Asciidoc to "hold your place" in a list, in case you need the first element in the list to be an admonition or block. Like so:

  . {empty}
  +
  WARNING: Don't catch yourself on fire!
  +
  Pour the gasoline.

  
    
       Don't catch yourself on fire!
      Pour the gasoline.
    
  

Anyways, I'm spitballing that these old-timey nulls I'm seeing are being employed in an equivalent way, some sort of internal bespoke workaround to a format restriction.

And my systems are all halfass, and I don't really know what I'm doing. I can't imagine actual real professionals letting that moulder its way downstream. Maybe their stuff is just way more complex and amazing than I can possibly imagine.

Of course, now, post-ZIRP, things are a wee bit different.

Which, I guess, says something about how expensive it is to run support for on-prem enterprise software. But that doesn't feel like an unsolvable problem, not with a customer field this rich. On-prem focused orgs tend to have wads of cash stuck up in them.

His true crime is a similar round of WTFs, like when you learn about weird CIA crap for the first time, but over and over again.

Mental note to watch the TV series - that somehow passed me by.

The few times I've been in bush flights over terrain, it's always felt like the man upstairs is punching my dance card. When I'm feeling brave I'll sometimes ask pilots about it, and sometimes they're like, yep, feels that way flying too - that's why I love it!

Whew, gonna have to have a hard disagree with you there. DaC is several times - nay, orders of magnitude - less complicated than standing up a S1000D, a DITA, or even a DocBook publishing system. For anyone.

Count the layers of configuration.

S1000D, you have to worry about issue (which has zero compatibility, and the Technical Steering says they have zero intention of releasing any guide to matching the different issues up), you have to worry about BREX, then you have to worry about bespoke DMC schemes, and then you have all the many ways the PDF or IETM build can get built out to Custom Solution X, since the TS/SGs offer absolutely bupkiss for guidance in that department (it's a publication specification that doesn't specify the publication, what can I say?). The DITA side's not a lot better: you have multiple DITA schemas, DTD customization, specialization, and you have a very very very diverse batch of DITA-OT versions to pick from, then on top of that you have the wide wide world of XSL interpreters, again with very little interplay. DocBook is probably the sanest of the bunch, here, but we're still going to be wrestling with external entities, profiles, XSL, and whether we're doing 4.X or 5 or whatever is in DBNG.

Not to mention all of this stuff costs money. Sometimes a whole lot of it. Last time I shopped round, just the reviewer per seat licenses for the S1000D system were 13k per seat per year, the writer seats were over 50k per year.

DaC, on the other hand, I want to get re-use and conditionals, so I get Visual Studio Code. I get Asciidoc. I get some extensions. I get gitlab, set up whatever actions I want to use, set up the build machine if I want one, and if I'm feeling adventurous, Antora. I'm literally writing an hour later. I'll probably spend more time explaining to the reviewers what a Pull Request is.

First, code is formal language, and docs are natural language. That's a lot of jargon; what does it mean? It means that the chunks inside of a piece of code are consistently significant; a method is a method, a function is a function. Chunks in a document are, woo boy, good luck with that one. XML doesn't even have line breaks normalized. Again, no matter what the XML priesthood natters about, it's natural language.

A consequence of this is that the units of change are much, much smaller in a repo of code vs a corpus of documents. This, well, is can be ok, but it also means that a PR in a docs as code arrangement can be frickin' terrifying. What this means, is that you have to have a pretty good handle on controlling the scope of change. Don't branch based on doc revisions, but rather on much more incremental change, like an engineering change order or a ticket number.

Your third problem is that the review format will never - can never - be completely equivalent to the deliverable. The build process will always stand in the way, because doing a full doc build for every read is too much overhead for basically any previewer or system on the planet. This is a hard stop for a lot of DaC adopters, as many crusty managers insist that the review format has to be IDENTICAL to the format as it's delivered. Of course, that means when you use things like CIRs (common information repositories) that you end up reviewing hundreds of thousands of books because an acronym changed....but I call 'em "crusty" for a reason. They're idiots.

[1] GitLens comes pretty close to this, however.

I'm going to head all this off at the pass, and say instead that DaC[1] is a technological tool for a limited number of business use cases. It's not a panacea, no more than XML publishing in a CCMS (component content management system) was seen as the Alpha and the Omega (and indeed still is by a whoooooole lot of people). I say this as a heartfelt believer in the DaC approach vs a big heavy XML approach.

Your first question - really, this should always be your first question - is, "how do people do their jobs today?". If you work in a broom factory, and the CAD guy reads word documents, the pubs guys use Framemaker, the reviews are in PDF, and the final delivery is a handful of PDF documents....well, using DaC is going to be a jump.

Now, is that jump worth it? Well, it might be. Your CAD guy might know his way around gitlens, your pubs folks probably have some experience with more complex publishing build systems, and, most important of all, you might have a change tempo that really recommends the faster-moving flows of DaC. If you're going the Asciidoc route, you could even try out some re-use via the `include` and `conditional` directives. But it also could be a disaster, with no one using VCS, no one planning out re-use properly[2], people passing reviews around in whatever format, and PDF builds hand-tooled each time. It's not something you dive into because it's what the cool kids are doing. Some places, maybe even most places legacy industry wise, it's just not going to work. Your task - if your job is consulting about such things - is to be able to read the room real fast, and recognize where it's a good fit, and where you might need to back off and point to a heavier solution.

[0] Big traditional XML publishing systems are also in the crosshairs, as they're quite frankly usuriously expensive, also writer teams have started noticing the annoying tendency of vendors to sell a big CCMS and then - once the content's migrated - completely disappearing, knowing that the costs of migration will keep you paying the bill basically forever.

[1] DaC defined as : lightweight markup (adoc, md, rst, etc), written/reviewed with a general-purpose text editor, where change/review/publish is handled on generic version control (git, hg, svn, etc), and the consumable "documents" are produced as part of a build system.

[2] Which crashes ANY CCMS, regardless of how expensive or how DaC-y it is.

Well, if they have, I suppose they'll be reminded forcefully by today's substantially different rate environment.

I'm not saying "AI" isn't a big deal. It is. It's got all sorts of uses. Is the state of play worth dumping this quantity of brains and dollars? Jury's out on that. But saying it's worth lots of money because people are throwing lots of money is not a winning argument.

Thing is, what you see in retrospect, is that nothing really dies all the way. Bits and pieces - sometimes very large pieces, in the case of Rome - can be digested and live on for hundreds or thousands of years. The current climate crisis will be a problem, no doubt, but it will be overshadowed rapidly by the conflicts that it sparks. Thirsty people don't worry about radiation.

It's why you see mostly kids with eff-off money in the game, a few kids from upper middle class, and the tiniest trickle of the actually poor. If you ever wanted a non-commie reason for UBI, that's one of them - you expand the entrepreneur pool by a metric buttload.