Growing up about books and software

As a teenager, I marveled over Stephen King‘s prose. I can’t even tell which book I liked more, though Christine, Talisman and Rose Madder probably stood out.

As a junior programmer, I slightly disliked managers, despised QA, hated technical writers and couldn’t figure out why anyone for God’s sake needed graphic designers. The Fight Club scene about “efficiency” totally made my day. Did you know you can swallow a pint of blood before you get sick?

And then I grew up.

My opinion about graphic designers became the first victim. I still remember James DeLaPorte at Gulfstream Aerospace back in 2003 explaining to me in simple arithmetic terms the cost of bad ergonomics. For example, an inefficient PLM system process requiring just a few more unnecessary clicks, screen and/or context switches, results in an A&D engineer wasting a half a minute or a minute of his/her time. Several times an hour. Each engineer makes a six-digit annual salary. Then you multiply this efficiency loss by several hundred engineers. Not to mention the cascading effects on other people waiting for these engineers’ work.

My disdain for Quality Assurance collapsed next, after I had started my company Senticore, hired developers, and then realized that their brains are simply not wired for testing. Unit testing, maybe, but even at that level too many issues were falling through the cracks. Automated testing tools did not really save the day either. Hence, deep gratitude for those poor leprechauns who day after day click the buttons and links across myriads of scenarios.

It took me several more years to entirely end my love story with Stephen King’s books and start deeply appreciating the value of technical writers. Quite proudly, I found myself aligned with Stanley Kubrik, who considered King’s writings “compulsive” and “imaginative” while simultaneously calling their prose “sloppy.” During the same period, I also immersed myself into the evolution of the Western political philosophy. It then dawned on me that too many of Stephen King’s caricature profiles were taken from an easily recognizable ideological playbook.

Technical (or documentation) writers are absolutely indispensable for any company’s long-term health and sanity. People leave, or just forget. Programmers, QA, system architects and project managers are not supposed to write documentation, and oftentimes they simply can’t. You need dedicated people to do that job. The problem is, technical writers are often not technically competent enough to work with the snobby-nerdy jerks. The jerks push them away, and then the writers mutate into indifferently-worthless walking spell-checkers.

Both QA and documentation are intrinsically on the receiving end of the changes happening in the environment. They are always going to start a fight, and they are always going to lose because they can never catch all these shapeshifting needles in the myriad of haystacks.

Technical documentation is not only about software. In the boring world of material goods, especially highly complex products like aircraft, “Operating Manuals” for existing and new parts/modules are of critical importance. These manuals are dependent on information coming from PLM systems. When the engineering changes and manuals are not synchronized correctly, technicians are desperately searching for holes, nuts or bolts that are no longer there.

In modern software DevOps, changes are in the job description. Presently, DevOps is in process of morphing to (or merging with) GitOps. According to Nicolas Chaillan and his evil friends, no pets are allowed, and everything including infrastructure, documentation and testing becomes code and can be slaughtered, replaced and automated. In this new paradigm, QA and documentation can finally catch up with the velocity of changes.

For Operating Manuals however, I am not aware about any existing framework allowing such a perfect sync of PLM to documentation. Perhaps full automation is impossible there, but maybe a good semi-automatic tool capable of linking the PLM graph to revisions to effectivities and further on will do? Incidentally, this might be one of the next big savings opportunities for large companies, especially aerospace and defense.

Growing up to 2022, I found myself with the books written before 1930s, even around 1700s. Compared to Daniel Defoe or Thomas Carlyle, Stephen King is simply boring.

Carlos Castaneda is one of the few authors that I consistently enjoyed from my teenage days to the present. Interestingly, in his famous “Don Juan” series he speaks precisely about expanding the imagination and personal transformation. We at Senticore are continuously learning new things, we are evolving to a better version of ourselves and we are helping our customers do the same.
Lastly, some technology is indeed available today for the engineering and manufacturing companies to synchronize QA and Documentation to PLM systems and eventually to the glorious MBSE paradigm. It often takes a lot of effort, and most companies are frightened of the price tag and history of failures. However, when executives truly understand the benefits and savings, and feel comfortable with a solid business case to support the effort, it will be hard to resist. For me it also looks like a hill for a startup to scale and win on.
Talk to us at Senticore, and we can help you create convincing business cases together with doing the job and/or aligning your needs with the right vendors. Talk to us, and we will show you the tech warrior’s way!