originally from a private forum, reproduced here by request. it’s commentary on this article about librarians as coders.
In general, I disagree with that diagram. There’s a level *below* application called ‘system,’ and it isn’t in that diagram because IBM wants to sell you systems that you write your applications on.
A relatively large number of systems suffer from lack of LIS-type knowledge at their cores, which then bubbles up through the various levels of architecture, and causes things like current OPAC implementations to be produced. Librarians (and people with librarian-type knowledge) are needed at all the different levels.
It also doesn’t discriminate between the different sorts of programmability that you might build into a system. Let’s divide programming (or ‘development’) into two fields, which we’ll call ‘Programming’ and ‘Scripting.’[1] ‘Programming’ belongs at the lowest levels of the system, and, as you might imagine, largely in the ‘Development’ phase of construction.
However, the graph is also missing a column called ‘Deployment,’ which comes after Development. This is where ‘Scripting’ comes in. ‘Scripting’ is the process of writing code to retrieve and manipulate information[2] from the system, and also changing the state of the system. In extension, it’s linking together systems made through the process of the three columns given in the article’s graphs. Why doesn’t it have this column? Because IBM would like you to pay lots of money to have all that nasty system linking done by their tools and IBM Global Services.
This nasty system linking is to a large extent easy to do on a system that makes hooks for it possible[3], and it’s a place where people who understand the information that they’re working with can add huge amounts of value to a business, institution, or whatever.
Following this logic, ‘Scripting’ is highly useful for librarians, etc… to know how to do. To the extent that it isn’t harmful to your business, keeping money and not paying it to large consulting companies is handy[4], but that’s a whole other discussion.
[1] note that the distinction between ‘programming’ and ‘scripting’ is to some extent informed by my own predujices and may offend some people, namely most people with programming ‘degrees’ and ‘certifications’ from institution name elided and also to some extent an undergraduate major at UW students. People who don’t have ideological stakes in being thought of as ‘real programmers’ usually don’t care.[1.5]
[1.5] I suggest that having an ideological stake in whether someone thinks you are a ‘real programmer’ is a stupid thing to do, even for ‘real programmers.’
[2] antelopes mostly.
[3] unlike, say, most OPACs.
[4] see how fast i change my tune if i get a job at a large consulting company.
-
I agree with your comments generally, and in particular with the idea that most librarians will get more value out of scripting abilities than hard-core programmer/developer/coder skills. I would however point out that the reason I selected that particular diagram was not to illustrate software engineering, it was just to show that there are more boxes in the process than “business person/librarian” and “coder”. A diagram with three boxes would have served my needs just as well. It’s not really fair to pick on IBM – they have lots more complicated diagrams that show all of the aspects they mentioned. I just picked the simplest one that demonstrated that there are many roles in the process of developing a system.

1 comment
Comments feed for this article
Trackback link: http://www.corprew.org/blog/2005/12/15/on-librarians-and-hackfests/trackback/