asking the right questions, when to be simple, when to be complex

Dan Chudnov has a blog called One Big Library where he talks about the programmming and social issues invovled in helping people build their own libraries, or making library data so that it’s accessible and usable and repurposable by others, or rather everyone else. I like the site because while some of it verges into the “blah blah programming blah blah” realm, he is always thinking about the human side of why our systems work and don’t work. This post about building simple systems and why that’s so darned complicated really helps me get my head around some of the technology hurdles we as a profession are facing in the age of interoperability and openness, assuming we’re even interested in moving in that direction.

If you’re a librarian like me and you take this example and turn it toward your own work to help people build their own libraries, it hits you… it is not simple to build a library of one’s own. And if you’re a librarian like me, you have a ready list of why not:

  • Metadata is complicated
  • People in libraries don’t all use the same items the same way
  • Maybe 20% of the collection is responsible for 80% of the use but that other 80% includes some really important stuff
  • Attempts to use new tools works great for new data but can be exceedingly hard for old stuff. Like, anything predating 1960. Which we have a *lot* of, and which is often *really* important.
  • Did I mention metadata being complicated?

Dan Chudnov “more librarians need to be coders”

I’ve been meaning to link to some of Dan Chudnov’s essays for a while now. He’s a librarian programmer, or a programmer with an MLIS, who works on some pretty interesting tools. Unlike many other people who can codeswitch between high-tech and low-tech aspects of the profession, he hasn’t eschewed one for the other. In fact, he spends an awful lot of time trying to bridge the gaps that exist. His work log should be on everyone’s rss feed list. The latest entry is about library development, not fundraising, but coding. Dan codes, for a library. Dan thinks more of us should learn to code. I’ll let him tell it.

There seem to be two levels operating here of relevance to library types: First, you cannot afford to be slow, so whatever it takes to learn how to do things faster and better. Second, don’t be stupid about being faster and better – the means exist today to design scalable platforms on top of scalable platforms, and tools on top of tools. So you’d better know what you’re doing, and you’d better be good at it. Or, you’d better know whom to emulate and take every possible advantage of their good work when it can get you up your own curve.

This kind of message needs to be broadcast profession-wide – at the TLA meeting this past April several audience members challenged my assertion that “more of us need to be coders.” My response was, and remains, that in the aggregate, our profession is borderline incompetent w/r/to software development, and the more people we can get who understand this stuff, the more likely our chances of basic survival as an industry.