Richard Akerman makes a great argument (with a diagram!) about why "librarians 2.0 don't need to be coders 2.0." He paraphrases an IBM article on service-oriented design that shows nine different roles as part of any project lifecycle. Sure, application development requires some hefty coding skills. But non-coders could be all over the business and architecture roles:

I just think "coder" represents such a small component of successfully delivering systems that meet your goals - think in wider terms about how to

1. Capture your goals (Business)
2. Translate those goals into sets of functions that make sense for the organization (Architecture)
3. Build systems that meet the business goals while fitting into your architecture (Applications)

His post reminds me of issues that arose during the OLC Futures Initiative. Quoting from the Technology Task Force Report:

The overall consensus of the committee was that, while all services should be examined for improvement by a specific technology, the services should drive the use of technology; technology should not drive the services.

Akerman suggests that maybe the reason library development seems so hobbled is that we have a communications gap, not a coding gap. (Still, it wouldn't hurt if more of us knew how to write code, or had the vision to hire staff who can).