So, I have been at Deichmanske bibliotek (Oslo public library) for several weeks now and I felt that it was time to write about our work here.
Firstly, I work with a team of nine, where I’m just a pawn in a larger game. In relation to previous roles I have had, this is familiar territory; I have been part of similarly sized teams before. The real change is that we have very strong focus on methodology and collaboration, which hasn’t been a strong focus of previous teams, perhaps because we chose familiar methods, or — at times — didn’t think it was important. What is clear is that we’re using methods that are new to the majority of team members and this is a very interesting area (I’ll return to this in a moment).
There are a number of a prioris in the project: Koha, the FOSS library system; test-driven development and adapting the software we’re producing to use in the new Oslo public library, providing services for what looks like a cracking play at the public library game. To cover these in turn:
Koha is a perfectly serviceable library system, but it is still a library system; it is often rather odd and counter-intuitive (as well as downright stupid at times), but this is not the fault of Koha, it is a problem in every system in use in libraries. Processes can be changed and services improved, but these require a massive amount of re-thinking and re-tooling that it simply isn’t going to happen. Without a shadow of a doubt, there is so much broken in the way library systems work that it would be an interesting to start from scratch, however, the massive changes this would require of the institution and its staff would mean the project plan would slide out of view.
The project aims at 100% test coverage; it isn’t realistic to attempt 100% coverage, however, providing 100% tested artifacts is possible. To this end, we use both feature testing and unit testing for the software we develop in house. All development is driven by feature testing — behaviour-driven development — which ensures that the software we deploy is functionally specified and provided with automated tests. Test-driven development should be familiar to most people, but how test driven a project is varies. I’d say that this particular project is very test driven; we’re also practicing continuous delivery and aim for a devops approach that integrates all of the aspects of testing as a necessary part of the process of developing, deploying and maintaining software.
Services are thus defined as features that form a specification that can be easily programmed. We’re aiming for functionality that grows incrementally; because of this there is no design up front except the features we’re working on in the current project iteration. It is interesting that there is a real struggle among team members (myself included) to accept the slow pace of building up the necessary framework to hold these — at times very complex — concepts in place; I take this as a very good sign as we’re all raring to get on with things.
We’re lucky in having very strong team members in the various domains that we’re working within; Oslo public library has over time built up a strong internal team with expertise in all aspects of deploying and managing new technologies built upon library systems in the public library space. The team is completed with external consultants (myself included) with expertise in project management, software development processes, semantic web technologies, library systems and general software development.
As we’re working within an existing institutional framework with pre-existing expertise, we’re using various technologies that are already deployed at Oslo public library. The nature of this expertise and devops approach has lead to a highly heterogeneous environment that I’m still not entirely comfortable with yet. I see that there is a great benefit in tools that are familiar for the other members in the team and I see how the choices we have made in specific instances are good choices, nevertheless I’m reminded of the long and painful process of getting to grips with JEE. Fortunately, I also see an end to this and feel far less at sea than I did a month ago.
One thing that I can really say that I am enjoying is getting back to pair programming, which is the best way to work as you’re able to do extraordinary things with two brains working in unison and you build strong relationships in this way. And the people I’m working with are pretty damned good…and also accept most of my weirdness 😉