I remember a friend of mine who taught introductory computer programming classes in University. One test question he always used was essentially ‘do something that people can do easily’. The exact details would change year to year, but the important thing is that the instructions simply stated “Sort the following list in alphabetical order”. Not write a program that sorts an arbitrary list into alphabetical order — sort this list. And, sure, you could write a program to do it. A program that would successfully accomplish the goal got an A grade. But so did someone who just took the list, sorted it alphabetically in their head, and wrote the list in alphabetical order. That answer? Would get extra credit. Because knowing when not to program is really important too. From a business standpoint, it’s a waste of money for someone to write a program to perform some easy one-off task that is never going to be done again.

I think about that a lot when I see “new” technologies getting picked up. I call it the “CIO magazine” approach to technology adoption. You see some new thing, have a very basic understanding of how it works, and decide we need to use one of these. And fail to consider if your use case is reasonable or if you’re willing to do the extra work for the “new” thing. The biggest example I experience of “not reasonable” is the prevalence of Java programming. If I am selling software, cross-platform compilation is A Very Good Thing. If I can maintain a single pipeline and a single release that all of my customers can use? Score! Internally developed software, though? We requisition specific platforms. Our Linux servers are not going to be Windows servers next Tuesday. I can write code, compile it for Linux, and be fine even if it doesn’t run under Windows. Because it doesn’t need to run under Windows. The extra work — our internal support groups adopted Agile. Except no one was willing to prioritize the ticket queue — so there’s no prioritized list of work to select from. Everyone has two “issues” for their sprint — “incident support” and “admin time”. A few people might get involved in a specific project and add “dns decom” or “nextgen vpn testing”. But sprint planning is repetitive (I’ve got incident support & admin time, too!), daily standups were a joke (I did tickets yesterday & had a meeting), and techs still didn’t know what ticket was the priority that should be pulled next. Which doesn’t make Java or Agile a bad idea — it just makes them overly complicated for the situation in which they are being used.

I think of all of this when I see Graph databases being implemented — step #0 is does a graph database make sense for my data? What would that mean? It would mean that the data elements are interconnected somehow — if you’d be using a lot of JOIN queries to interact with the stored data, then a graph model might make sense. If you’re just selecting items from individual tables where values are whatever? Then a graph database is a complex way of storing and accessing that data.