Technical articles about industrial software.
A kind of interpreter service for non-informaticians. With depth for experts.
Technical articles – or even more comprehensive white papers – describe what kind of problem is solved with what kind of IT. Two to four pages are not too much for this. All influencer trends notwithstanding.
The focus of the text should be on the solution, not on the technology and its particular manifestation as a software application. Readers expect the benefits of the application to become quickly apparent to them. To this end, I like to work with the vendor’s experts to describe this benefit as concretely as possible.
If the text is to be presented to a decision maker who has nothing to do with the use of the application itself, it must also be understandable for a layperson. If possible, it should be so specific that the return on investment behind it can be seen immediately.
The Läufer research project at TU Darmstadt used the digital twin to investigate, among other things, the aerodynamics of the tandem recumbent bicycle. Exciting insights into the research.
Illustrations that show the benefits are helpful. With software, this needs to be well thought out. Screenshots with tables and text columns are usually neither descriptive nor helpful. I also see this side of a technical article as part of my work.
My own experience as a software developer is long enough ago not to fall in love with details. My experience from hundreds of conversations with software developers and users ensures that I know what to ask for and when I understand enough to be able to explain a solution to others. Generating source code is one thing. But without a good description of the solution, it won’t get to the users. But that’s what matters.
On the occasion of my little series on 40+ years of CAD, there was an interview with Jim Heppelmann and Jon Hirschtick from PTC.
Article in Digital Engineering Magazine about the Requirements Interchange Format ReqIF, standard for exchange of requirements.
