Re: Management of products and projects

[Eric Lease Morgan <eric_morgan@ncsu.edu>]

Karen Harker (Karen.Harker@UTSouthwestern.edu) wrote:

> I am interested in learning how librarians manage the systems that are
> developed in-house. Is it all done ad hoc? Do you use a set of procedures or
> standards?  
> 
> Also, how do you handle maintenance?  Is there any documentation that a new
> staff member could review?
> 
> What I'm really wanting to learn is if there is a need by librarians for
> development organization and standards?  I'm currently developing a set of
> procedures, standards, and documentation for our myriad of applications
> developed in-house, mostly by me.  This came about because so many other
> librarians and staff were concerned about me leaving (it's nice being needed,
> but their concern was mounting).  Has anybody else experienced this reaction?
> Is there a need for libraries to manage their Web development, even if all
> they do is static Web pages?

Here at the NCSU Libraries we do not have standards, per se, but there are a
number of guidelines we (I) try to follow.

First of all, use computer languages and programs that are familiar to
staff. Just because you know how to write in Assembler does not mean it is
the best language for the stated purpose.

Second, write good code. One of the things this means is that you should try
not to hard code as many things as possible. Declare a set of constants at
near the beginning of the program that allow you to modify the program's
behavior as file system's change and email addresses become obsolete.

Third, work with the people who will be using the program as the program is
being written. This is a sort of usability procedure that heads off any
problems that may occur because of your implementation.

Fourth, document your work. There are two types of documentation. First,
there is documentation taking the form of comments in your code. Use them
liberally, and use them to write a history of changes. Second, write
documentation, usually in the form of Web pages, describing why the program
was written, how it works, and how to use it. Do not put this off. Write
this as soon as the program is complete. It will save you gobs of time in
the long run and make you look really good to the non-programming staff, as
well as people outside your institution.

-- 
Eric Lease Morgan
Digital Library Initiatives, NCSU Libraries
http://www.lib.ncsu.edu/staff/morgan/