Check out this column, “Top Ten Idea Killers in Software Development” by Navneeth Mandavilli. on the IEEE web site. “Killer” there means “will kill your software”, not “great”, ha.
I think it does apply to any library that does any in-house software development at all (even little tiny widgets and integration mash-ups): It is our job as professional writers of software to write good software — or to do the best we can (I, like everyone else, look at software I wrote three years ago and think, god, how could I have written such crap? I suspect this happens to even the best programmers; if it doesn’t happen to a programmer, it’s probably because they in fact aren’t very good and never improve!)
It’s our job to write good software — maintainable, well-architected, properly designed software — because it serves the interests of the organizations we work for. A library essentially is an IT organization these days, software is incredibly important to it — if you write terrible unmaintainable software, the organization will pay for it down the line, this ‘technical debt‘ will have to be paid. Either in huge amounts of development time to fix what you didn’t do right, or in having a really crappy software environment for our users that never gets fixed. I know we’re all familiar with both phenomenon.
(Yes, this also means that if a library is doing any in-house programming, and many many are these days, it is terribly short-sighted of them if they don’t hire professional programmers, or get training for the non-technical staff that ‘just fell into it’ — the cost is worth it, do it right or don’t do it).
Anyhow, here’s some of the ideas Mandavilli identifies as (in my interpretation) barriers to excellent software. I’ve highlighted the ones I know will be familiar to anyone that writes software in a library environment.
- “There isn’t enough time to do it right.”
- “Management has not prioritized it” In our context, this might be “the committee”, or “the reference librarians”, not management. Mandavilli says “what exactly hasn’t management prioritized — making a good product?”
- “No one is asking for it” Yes, we have to be user-centered, and in the library world we’re still trying to do that, but being user-centered isn’t just doing whatever people explicitly ask for and nothing else. Mandavilli says “This reminds me of Henry Ford’s wry comment “If I’d asked people what they wanted, they would have said ‘a faster horse’.” Yes, this applies to reference librarians too.
- “We have to have consensus” Mandavilli says “Someone has spent years studying, learning and working in a specific field, and to not defer to that person for the final decision is to waste all that expertise, not to mention deliver a bad product, demoralize the expert, adopt the safest and most timid way and most insidious of all,diffuse accountability…. A group decision is a way to duck responsibility for the outcome. ‘We all decided together’ is a way of saying ‘No one is responsible'”. jrochkind says: Oh boy, sound familiar? I suppose it’s somewhat comforting to learn this disease is not unique to library organizations.
Read the original article, there are some more in there.
And if you write software in a library, commit to software excellence. Commit to fighting for software excellence against the other forces in our organization (and in our heads) that work against it, to convincing managers and committees that software excellence matters, and that to get it you have to give the software experts responsibility and authority to do it (as well as sufficient resources to support the desired outcome). No matter whether you learned programming in school or on the job, commit to continuously improving your craft by looking at others code, by reading, by taking some courses if needed, by peer-reviewing your peers code and getting your code peer reviewed (by a peer at another institution if you don’t have one at your organization) and by reflecting and evaluating on your own code.
Do it right or don’t do it. If you can’t afford to do it right, you can’t afford to do it at all, doing it also crappy is something we can not afford. Now, it’s true that there is an opposing danger of over-engineering and micro-tweaking and never getting anything done. Finding the balance is perhaps something that only comes from experienced developer intuition. But I think libraries tend to err on the side of ‘crappy’, for various reasons. If you’re a programmer at a library, it’s your job to develop that intuition and experience, not to settle for crappy.