It’s A Good Thing That We’re Not A Software Company.

I sometimes say that when I’m thinking about something that people in my company have done, are doing, or even contemplating, because there are things that fall into those categories that, by god, would be done Better if we were a software company. I occasionally wonder if this attitude comes from my inherent desire to improve things, or experience, or some latent pool of snarkiness that only occasionally bubbles to the surface – you know, when I’m out hunting for food. (Apologies to anyone who doesn’t get the reference.) As always, there’s a Dilbert strip that encapsulates the concept: he’s talking with other engineers to their manager, and they say that for a project to be successful, they’re going to need coffee cups emblazoned with the logo for the project, and they’re going to need to build a database. “We like databases”, he adds.

Databases is what I was thinking about this morning. (Are what I was thinking about? Which for some reason reminds me of the quote from the US Senator who was being introduced to the concept of databases as part of testimony in some corporate malfeasance examination. He wanted to know what a database looks like – and how big. Would it fit into a shoebox? The hearing room? A football stadium? For those who know what a database is, this is a ludicrous question, but he was serious. He hadn’t a clue.)

The origin of the thought was a conversation my wife and I were having about an informational document that her company uses to let the systems programmers (used to be called ‘systems engineers’ but then the real engineers started complaining about the abasement of the term) keep track of pieces of information about the 70+ systems that they maintain – system name, location, file names, oddities - that kind of thing. This information had at one time been kept in a text document, and then transmuted into a spreadsheet, and then into an HTML document. That most recent transfiguration allowed lots more information to be there (a Good thing) but it also meant that the document was no longer compact, and therefore not easily printable. Well, expostulated the HTML advocates, its still a Good thing because it has all that info! Yes, retored the spreadsheet advocates, but the intent is also to be portable, and HTML format isn’t easily printable, so therefore not easily portable.

It brought to mind an argument in my company about the documentation we use to keep track of the systems we support, and the characteristics thereof. One is Marti’s List, which is owned (though not maintained; heaven forbid) by a senior manager, and lists system names, support groups, and that sort of thing. Another is The MVS Group’s List, which is owned by a different manager, and maintained by a person in the MVS support group; it has a lot more systems, and more contact names (though not all, not by any means). A third is the Security Group’s list, which has just the systems they support, and details of interest only to that group. It’s not beyond the realm of possibility that there are other groups. I tried (reasonably; I’m always reasonable when people agree, or at least do not vigorously disagree, with me) to tell people that what was needed was a core list (here’s the systems) and then links to places with group-specific information. Or, for the Dilberts, perhaps a relational database? No, the response was. We Like Our Lists.

I think that it's an intruiging question -- is there a best way to organize data? Or, failing that, is there an optimal way, given disparite needs of users? And, of course, the needs vary by time -- I want it all by type; I want it all but just for this system; I want just this system and only these groups. I think you could spend years on the concept -- like a PhD dissertation.

It’s a good thing we aren’t a software company.