lib4code
Thanks to Jessamyn I found Librarians 2.0 donāt need to be coders 2.0 where Richard Ackerman has an interesting take on just how important programming skills are for a library technologist. Richard cites a paper from IBM on Service Oriented Architectures to make a compelling point that there are many roles to play when building technology solutions, particularly the web services that comprise such a big part of ālibrary 2.0ā effortsā¦and that coding skills really arenāt that important when you can just get a student, consultant, or vendor (heh) to do it.
Itās unfortunate I think that the code4lib 2006 conference name seems to emphasize ācodingā so much over the ideas. I totally agree that the most important aspect of our work as library technologists are the service ideas, and that the code is simply a machine readable description of these ideas. Some high level languages are actually really, really nice for expressing ideas, and I would argue that often times learning a good computer language can help you express your technology ideas better. As Martin Fowler says:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Let me go on record, as someone who has helped organize the code4lib conference, to say non-coders are more than welcomeā¦there will be plenty of people who can program thereā¦we want ideas, mindshare and collaboration. Please donāt let the computer programming jargon dissuade you from participating.
Also, a few things stood out to me eye:
If your goals and architecture are clear enough, the coders donāt need to be library experts in order to deliver the functions you need.
The coders donāt need to be experts, but wouldnāt it be nice if they were, and you didnāt have to go into great detail about certain things? Wouldnāt it also be nice if the coders didnāt start from scratch and were aware of good reusable components from the library software community which could be leveraged to make the software construction phase that much faster? Indeed, architectural decisions often have a direct effect on programming decisions that are made, and it helps if those who are architecting things have at least a general understanding of how software is built so that designs stay doable and saneā¦and so that theyāll know when things are drifting of course.
Also, donāt try to build big complex systems. Live in the beta world. Get some chunk of functionality out quickly so that people can play with it. The hardest part is having the initial idea, and the good news is I see lots of great ideas out in the library blogosphere. I can understand the frustrations in the gap between the idea and running code, but I hope Iāve presented a bunch of areas above in which you can work to turn the idea into the next hot beta, without necessarily needing to code it yourself.
The one danger to moving to a formal process like the one described in the article by IBM is that it may encourage you to build big complex systems on a slow time scale. If you need to thoroughly describe a software solution before beginning to program (the so called waterfall model) you will be spend a lot of time trying to get the design right before even beginning to code to see what actually works. Iāve found the more that the design and the coding can be intermingled the betterā¦since it lets them both inform each other as they go on. This intermingling is easy if you are a small shop and you have a handful of people (1-8) that need to communicate on a regular basis. I imagine most software development groups in libraries are around this size. That being said I think that Richard is right, itās good to be aware of the different roles that are being played, perhaps by one individual.
After seeing Adrian talk about software development and journalism at Snakes and Rubies Iāve been thinking off and on about the space between libraries and software development. Iām particularly interested in how one informs the otherā¦and found Richardās post to be a good catalyst.