The Importance of Technical Communication (A Remembrance)

When I first started my MS in software engineering, I thought that the required technical communications course would be easy, given my extensive writing experience.

I was wrong.

My professor, Dr. Robert (Bob) Waite, was a principal software engineer at IBM in Rochester, MN. Sadly, I learned on July 23, 2015 that Dr. Waite had passed away a few days prior.  Dr. Waite was a fascinating guy; he had a PhD in English, but had gone into the tech industry. I’ve since met others like him, and written about the trend, but he was the first I had met. Given my own undergrad work, this in itself made him interesting to me, but he was also working on the IBM San Francisco project, which was developing a common business object platform (initially in C++, but later moved to Java) by (and initially for) organizations looking to move from COBOL, RPG, & AS/400s to the modern world. The project ended up failing, but not because it was bad; it was ahead of its time, and subsequent technology (in particular EJB) supplanted it. Brad Rubin, also faculty in the University of St. Thomas’s Graduate Programs in Software (GPS), was on the project, too, and authored the principle paper, linked above. Now, EJB failed to deliver on its promise, too, but that’s a topic for another time.

San Francisco was, in the early days of Java, the largest Java project in existence (although the company I worked for at the time, ServiceNet, claimed to have been the first to break 1 million lines of code in Java). Any project of this magnitude  needed extensive and stellar documentation, and this was Dr. Waite’s task. Thus his expertise was deep, which is what made GPS a great experience.

Dr. Waite actually gave me my first A- in grad school, and my only A- at the MS level, but I don’t hold it against him. Much. The work we did, all projects, included:

  • A memo (my first group writing project, and surprisingly useful)
  • Comprehensive documentation for a TinkerToy device we built as a group, including construction and usage instructions
  • A prepared presentation (I was exceptionally nervous the night before, as this was my first presentation, and I must have prepped that 5 minute speech 20 times)
  • A manual on a software project of our choosing based on the model in Weiss’s brilliant How to Write Usable User Documentation (I chose my current company’s database interface architecture)

Dr. Waite also introduced us to TJ Watson’s “gobbledygook” letter, which I love, and which is critical of the use of, e.g., “utilize”, where “use” works just as well.  When I expressed further interest, he led me to John M. Carroll‘s excellent The Nurnberg Funnel, which established through research the general ineffectiveness of most user documentation and the difficulty in making software actually user-friendly, and established a new standard of minimalist documentation. The book influenced me profoundly, and while it’s not among the most read books in the area, much of the subsequent documentation and the trends in how to write documentation moved to this minimalist model. The book also introduced me to human-computer interaction (HCI); my home lab for my PhD was the Penn State Laboratory for Computer Supported Collaboration and Learning, of which Dr. Carroll is the co-director. Dr. Carroll also served on my dissertation committee, and I learned a great deal from him.

Dr. Waite profoundly influenced my career and life, and at two levels. First, he made me aware of the complexity of communicating about technical subjects, and that this complexity made tech comm a fascinating field of study that holds a great degree of importance for software engineering specifically and IT generally. Second, he introduced me to new topics that would take me through my master’s degree, my career as a professional software developer, and beyond into my PhD and post-PhD career.