Deep down I always knew I wanted to be a librarian. I loved working in the school library and when I left school and went to college, I missed it so much I asked the college library if I could volunteer.
The librarian had to be persuaded to let me work as a volunteer and from that point on I didn’t look back. I continued working in libraries (College, Public and then Law) through until 2007 when I joined Soutron.
I woke up one morning after being at Soutron for about 6 months in a panic with the realisation that I was no longer working in a library! I was stupefied. It was a weird sensation and for a brief moment I thought, “my goodness, what have I done?” I always saw myself working in a library. I simply loved it! But then as my breathing steadied, I thought, “this is even better! now I get to work with lots of libraries”.
Looking back over the last 12 years, I have had the great pleasure of working with different types of special libraries and librarians. This has also allowed me, occasionally, to continue being a real librarian. I get to do this with the single objective of developing great software that I am proud to deliver for use by fellow librarians and information and archive professionals. Being a librarian has, I believe, helped me to produce better library software and influence the development process for the better.
When developing software, there are three phases.
Getting the design right is very important. It defines the scope for what is going to be created. Developing the code using Agile Development methodology is critical and using this methodology allows the design ideas to be adjusted in the light of experience and experimentation.
Building software is very different to building a physical object like a house. Once the foundation is laid, if there is a problem it can be very difficult to put right. Software, however, when developed using an agile approach, allows the foundation to be altered as it is being built. This leads to an end result that works!
The downside of this approach is it can extend the delivery time, but the end result is always, in my experience, a better product. The new Soutron serials and acquisitions workflows are a testament to this. We took a very different approach with the original serials and acquisitions programs back in 2010/11. It was the first and only time that I used a non-agile approach to developing code. Never again!
A lot of time was spent on the “design” phase and a very detailed specification was created that looked great on paper. It was signed off and handed to development to build the product. The result was exactly as specified but using it did not live up to expectations. Although technically it was a great piece of work and well architected it simply did not simplify the processes. The testing phase was made easier because we could clearly match the code to what had been specified. The specification could be easily followed to check everything was working but there is something about software that is intangible and comforting when it works.
An agile approach to development makes testing that much harder because the application is being developed with tweaks and sometimes big changes. The developers will also suggest alternative approaches taking advantage of technology to improve things. It also means as the functionality is developed we can see it and test it, so if we don’t like something, we change it. We don’t have to wait. This means we have to record carefully all changes so that when we come to final testing of the completed application, we are testing against all the changes rather than what was originally specified. This all takes time but the result is a much better solution and better software.
Testing is broken down into three parts:
When testing software, it is initially done from a technical point of view. Does the program code do what it is supposed to do? Then it is examined from the point of view, does it work as envisaged in the design phase? Looking at the specification and any changes made. Once the functionality is working and can be seen, some clients like to get involved in testing, especially new and exciting features. This is the first time that the code will have been tested from people who are to use the system, day in day out.
Even at this stage the testing can be mechanical in that the focus is on the functionality. This may not necessarily align with real life day to day workflow, although we all try to do this in reality, it is not a true test. The real test comes when 2 or 3 keen clients offer to be the first to be upgraded with the new programs and versions. When they start using the system, it is inevitable that a few “gotchas” appear which can be quickly resolved and addressed. Compared to the early software that we created, these “gotchas” are few and small and generally minor bugs which are easily resolved.
This is due to a number of factors.
Agile development methodology plays a key role. From the moment code starts to appear, we start testing and adjusting. This does not stop until the software programs are completely finished.
Using the latest technology available is a significant benefit. When we took the decision to re-engineer the application in 2015, we could have chosen to develop on top of the original system, continuing with the tools we had used before with a few amendments. But that would create restrictions and prevent us achieving the goal of greater efficiencies, better performance and simpler use.
Instead, we chose to re-engineer from the ground up. Yes, this meant going back to the drawing board and re-creating the system: User Interface, workflow, business logic and usability. Although this meant we would need to take a lot more time and invest more resources to complete, it was 100% the right decision. The end result is fantastic!
Keeping the design and workflows as simple as possible is critical, keeping functionality within one page makes testing a whole lot easier too. The approach we take has seen the implementation of brand-new workflows in serials and acquisitions and the response from clients has been very well received. This works so well and allows us to continue to refine and re-engineer our application.
As a librarian, someone who thinks attention to detail is important, I also want to iron out those little things that might be overlooked by staff users because the system works, and they are busy.
I am always looking to see how things can be improved further to get the best experience. I remember being an end user and the experience of frustrations that inevitably arise using software. It is for this reason, that a few times a year, I like to get out and be a librarian again. Being a Law Librarian, the most natural place for me to do this is in a law firm and I am thankful to some of our legal clients who have allowed me to do this.
I get to do what I have been doing since I first started working in a library. I turn up at the library, get assigned a desk to work at and do librarian work that involves using the Library Management System.
I did this several times to learn what people experience when using the previous version of Serials and Acquisitions. What I learned, combined with client feedback, led to the development of the new workflows we have today. This allows me to get my hands on the software in a real-life environment.
Last week I had the opportunity of doing this again (whilst on holiday!) by spending several hours in a law firm library setting up lots of new orders, doing some check-in and other workflows. Doing this is invaluable as I immediately get a sense of how the application is performing. The new workflows allowed me to set-up things quickly and efficiently. When I had completed all that had been given to me, my client could not believe everything had been set-up and completed in such a small amount of time.
Of course, it does help that as the software author I know how it all works but I would never have achieved this using the previous version (the non-agile developed version). All applications can be improved further. My experience last week identified a number of small things that could be done to make things even better which will go into the future development.
It is a “win win” for both us: as the supplier, in that we get to see first-hand how the application is performing, and also the client gets a little bit of help with setting things up.
Most importantly, it keeps my passion and excitement for what we do very much alive and drives my desire for excellence and developing simply great software that we can be proud to deliver and our clients love to use.
To follow Graham, the Travelling Librarian, on Twitter and find out where he is and what he is up to. Follow Graham on Twitter today.
Graham Partridge
Research & Development Director
> Soutron Library Management
> Soutron Records Management
> Soutron Archive
> Soutron Business Archive
1989 – 2024 © Soutron Global Inc – All Rights Reserved | Terms & Privacy | Sitemap
