Writing

Software, technology, sysadmin war stories, and more. Feed
Monday, July 1, 2013

Simple-minded literalism and avoiding the big picture

Back when I was in school, I had more than a few classes which were utterly silly and yet couldn't be avoided. The worst ones centered on a single implementation of a certain technology. That is, instead of being about spreadsheets, it was about Excel. Instead of being about word processing, it was about Word.

There were some seriously broken assignments which went along with these classes. One of them was something like this:

So and so created an Excel workbook to track his video game collection. He has headings and wants to sort on Name, Date Purchased, Purchase Price, Size and Location for each game. His wife wants to know how much he's spent on this hobby, and his son wants to know when he started this collection. He also wants to know which games were purchased prior to 2000.

This screams "SQL database and a handful of SELECT queries", doesn't it? Being able to say "use a database, you idiot" would have felt good, but they wouldn't have accepted it, since this was a spreadsheet class, and specifically was all about whatever version of Excel was current at the time. I could have said it but it wouldn't have accomplished much.

It took me a while to realize what I had to do to make this work. Part of the problem was understanding that my own internal monologue for how this should work was down on step F or G and they wanted me to explain step A. That is, instead of talking about the fundamentals of the problem and proposing something which went with it, I had to get down to basics and just cough up a list of actions.

Create rows and columns. Columns are the name, date purchased, and so on. The rows are individual games. The various cells get filled in appropriately. The columns are tagged with whatever formatting might be needed, if any. Then they should be resized to avoid truncation if at all possible.

This is all obvious to me, but I had to write this as if for an audience which had no idea what was going on. To someone with the same context as myself, there would be nothing to say, but for this hypothetical user scenario, it would be rather different.

This assignment was actually conducted using the class online forum where everyone first posts their essay and then responds to those of several other students, so assuming anything about the reader was dangerous at best. Some people in there had probably never so much as touched a spreadsheet before this class and would have no idea what I was talking about unless I was very careful with my wording.

I guess this video game tracking situation doesn't really exist in my world, since so many of these things can be solved as a "Simple Matter of Programming" (tm). Sure, most of the time when I describe something like that, it's intended to be snarky and calls attention to the fact that a problem is distinctly non-trivial, but not always. Some problems are in fact the sort of thing which can be handled by gluing together a couple of existing modules.

This one would need some kind of database, and the exact implementation isn't that important. It could be a flat file, MySQL or Postgres, SQLite, or some funky NoSQL thing and for this problem space it would not matter. There just isn't enough data for it to make any difference. Then there would be just enough of a frontend to collect data, and a viewer to render the results. That's it. A specific problem gets a specific solution. Trying to be generic would be hard, so I punt on that.

The spreadsheet neophytes don't live in a world like this. They need a very blunt hammer to solve their problems. Maybe the world would be a better place if they had tools to let them do the Right Thing which didn't create too much of a stink. In that sense, having them use spreadsheets might not be so terrible.

The essay I wound up writing focused on the exact things to do in Excel with none of the "bigger picture" / existential view of what was actually going on. I talked about the problem at hand, and then described which labels should be created and the cells where they should go. Then I explained where the different data points would go and the cells which would hold them.

I even went as far as describing the right-click action on top-of-column label for dates to enable the magic formatting for that kind of data. This way it would know to treat those numbers as dates and not guess as to what it might mean. This repeated for other columns with potentially interesting data - prices are currency, for instance.

Then I laid out how to select the data (dragging, or clicking that weird corner box thing) in order to feed it to the sorting and filtering flow. Everything else followed from that.

It answered everything which had been in the problem description with stupidly simple language and offered absolutely no "outside the box" thinking.

They loved it. I got an A.

Sigh.