In the organisation where I am employed there is a dual, almost schizophrenic, nature to the work that I (and the other software engineers in my team) do there. Our funding comes from several sources, but a large portion comes from academic research councils. The nature of this funding is that it involves short-term projects that focus on research materials and on developing internet technologies to deliver those resources to the academic community in the UK in novel and groundbreaking ways. To do this work requires a specific type of software engineer, and one who is happy to take on new challenges where there is little supporting documentation (because very often no-one else in the whole world is doing quite the same thing), a very small but knowledgeable audience of users (typically research academics and information specialists like librarians and archivists), and where the limitations of the funding require that all the software development (and sometimes the project mangement too) are done by exactly one person, perhaps on a part-time basis.
Sometime these projects lead on to bigger and better-funded things; sometimes they don’t. I guess this activity can be described by the (now a bit old hat) term ‘research and development‘.
This kind of work can be very challenging, interesting and rewarding, but it stands in stark contrast to the other type of work my organisation does: to provide data services to the UK academic community. These require well-developed and mature software applications that can support a very large user base, have service level agreements with the funders (who in turn supply long-term funding), and need dedicated human resources to support them (i.e. user support in the form of a help desk and training teams, and a team of software engineers on hand to provide service cover and to fix problems that crop up, sometimes outside the normal 9-to-5 working hours and always immediately; for a service to be down for more than a few hours causes a lot of problems).
However, in my organisation, this doesn’t work for a very simple reason: the same software engineers who do the development work are exactly the same who support the services. They spend their days multi-tasking and trying to do both roles at once; as employees they are required to have split personalities. It doesn’t take a management genius to see that these two types of tasks need to be separated. The principle of Divison of Labour is as old as Plato.
Developing new software applications for researchers often requires that the software engineer working on this attends academic conferences to learn about the issues and to speak directly to the potential users to establish their requirements and to demonstrate prototypes to them for feedback. Sometimes software engineers and researchers collaborate on research papers that are written on the strength of this development work. All of this cannot be achieved by a software engineer who is required to also be on-hand at certain hours of the day each week to support a live service that has thousands of users.
Sometimes development work is required for a new version of a service; but again this cannot be accomplished by the same group of software engineers who maintain that service. Someone who is concentrating on fixing bugs and responding to unexpected service downtimes (i.e. system crashes – they do happen) cannot at the same time concentrate on the development and delivery of new code under a project with immovable timelines and finite funding (are there any other kind of projects?). A separation of tasks in this instance does not of course mean that communication between development and service support teams is unnecessary; quite the opposite.
A lack of employees to support this separation of tasks is often cited by management as the reason why the old way of doing things is maintained. As far as I can see, the old way means each software engineer has no focus, and instead of them doing two or three things well, they do six or seven things badly. Using exactly the same number of software engineers but dividing their time and responsibilites logically between development and service support, is the answer to this. It does not require employing more software engineers (which can bring its own problems; see my earlier posting ‘In defence of Cowboy Coding‘).
The team I work in develops applications and supports services that deal with resources and data that are primarily of a geographic nature; the following quote from the standard undergraduate text book, Geographic Information Systems and Science, is therefore particularly apt (my italics added for emphasis):
“It turns out to be rather difficult to operate equally well in any two of the three vertex areas [Core developer (software, data), Services provider, System integrator]; it often causes internal prioritization problems and difficulties in relationships with business partners who see this as competition.”
1st edition 2003, ch 16.6, pg 361
Alpine Dreamer
If it’s any consolation, you’re not the only one who thinks this is totally schizoid. I do too. I’ve had the logic explained to me on many occasions by someone we both know well, who makes the decisions and orchestrates this madness. Sometimes I see what he means, and sometimes I think it’s completely barmy. Either way I find it phenomenally frustrating that we seem to do so much and still end up with the same problems. Divison of responsibilities is never clear, we have very little in the way of failover systems (human not machine…), and there are several single points of failure (that doesn’t make sense logicall but I’m sure you know what I mean). I have tried to change things wherever I can, but voicing my concerns, and pointing out various flaws, but to date I have been overruled on every occasion. It’s quite demoralising….so where next? I don’t know….