When everything is a table...

It is perhaps a side effect of getting older that I spent more and more time on administrative issues and as a consequence I interact more frequently with people working in administrative offices. The more I get to see how they work, the more I am realizing how strange computer scientists are. One of the first rules they seem to learn in business administration is that everything can be made to fit into a two-dimensional table. And then they seem to drive this to perfection during their career. We computer scientists love to model things using inductively defined structures that can be nested arbitrarily deep or we paint walls with UML diagrams or model data in N dimensional sparse spaces. We teach our students how important it is to find the appropriate data representation for a given problem since often algorithms follow from the way data is represented. But this may all be misguided effort since business administration proves us every day that a two-dimensional table is a universal tool for everything.

If you ask a computer science person to take minutes during a meeting, you likely get a structured document back with multiple nesting levels, etc. If you ask an office person instead, they likely open a text document and in there they create a table and then they write notes into the boxes they have created. Recently, I saw the design of a web site in excel…

We teach our computer science students that handling versions of documents and source code is of key importance in software development. We tell them versions are not just linear, not a tree structure, but in reality form rather complicated graph structures. And then we introduce students to tools and algorithms that can handle documents at many different versions and the relationships (diffs) between versions. And we explain that good development environments have issue tracking systems, that resolutions of issues should be able to point to changes in the versioning graph, that it is important to have tests that are automatically triggered when changes are made, etc.

How are similar problems handled in administration offices? The ultimate versioning system is still most of the time a set of labels added to file names. Issue trackers are long discussion threads stored on page margins. Issues affecting multiple documents are tracked in separate excel sheets. The tracking of which version incorporates a certain solution to a problem is done using yet another excel sheet that refers to file names with funny sequences of embedded dates and acronyms. And if changes need to be propagated into multiple documents, well, you hire more people to do the edits.

Sure, some office tools can do much better and there are people in business administration who do much better. But still way too often, I see a two-dimensional table used as the tool of choice. As one would expect, this should remind computer scientists of the proverb known as Moslow’s hammer: “If all you have is a hammer, everything looks like a nail.” Perhaps we have to give people an opportunity to experience other tools that can get work done.

Needless to say, we can make similar observations within the computer science field. In computer science, we have over the years developed many programming paradigms and programming languages and some are considerably better than others for certain purposes. However, significant parts of the industry still love writing C++ code. The first programming language students learn frequently has a profound impact on what they perceive as programming and then things carry on. The push towards Java as the first programming language that started some 20+ years ago undoubtedly has made Java (and close derivatives) much more popular in the industry. But is Java the proper answer for every problem? Surely not. But some people use it like a hammer.