I’ve just finished my first four weeks as a public servant in one of my states’ largest departments. I think four weeks is a long enough period to get an initial impression of the differences. I’ve spent the first 13 years of my software developer career in the private sector working for a range of small companies. I started with a company that produced their own financial software which they then sold and supported, essentially producing a shrink-wrapped product. Next I worked for a company who resold and supported emergency services dispatch software as well as modified and extended it for the particular purchasing agency. The latest former role was at a company that is essentially a consulting company, producing media rich websites for a large telecoms enterprise, where the company owned no IP. Currently that leaves me where I am now, working in the public service at a department with over 8000 staff and an software projects department that numbers in the hundreds, including developers, business analysts, project managers, and software trainers. My role is managing the developers in one of the division – about 30-40 developers across, at the moment, 6 projects.
The first and biggest difference, one that has to accompany any enterprise of significant size, regardless of it being in the public or private sector, is an unavoidable level of red tape. The public service is no different and I was immediately exposed to this. It was four days before I was added to the AD (Active Directory) groups necessary to do my job, leaving me essentially twiddling my thumbs (although I did read almost the entire main intranet in that time :p) for four days.
Once I started work though everyone was generally friendly and I immediately felt one of the team, something that I hadn’t really experienced when starting other jobs, although this may be now due to my experience and confidence at my new role.
The project methodology used for software development projects is Prince2 run SCRUM style. All teams have a physical whiteboard in the Pod (a collection of desks and performs a function like a war room). On the white board is the product backlog for the current sprint, along with the items in dev, test, and completed stages. We do lack a continuous integration server though, which probably doesn’t make a lot of difference given no one seems to write unit tests.
The lack of unit tests in an interesting one and even in light of overwhelming evidence suggesting unit testing is a must, may not be a bad thing. Earlier in the month I debated the use of unit testing with a senior dev. His stance was that unit testing only slows the project down and we need to be focussed on delivering to deadlines. It is true that writing unit tests can slow down how much production code is written, but it also helps speed up development, in that it provides a safety net to code against and developers can more easily write new code or refactor, feeling safer that the CI server and unit tests will catch anything they missed (although that doesn’t mean developers don’t need to understand how the code under development impacts the system at large).
As public servants, perhaps we have an obligation to deliver products as quickly as possible, wasting as little tax payer money as possible. Therein lays the irony. By getting products “out the door” faster, we may be compromising maintainability. Live software is maintained by a complete separate department and the original developers are not called on to touch software once it passes the final gate and is in production. The project managers know this and they too aren’t focussed on the maintainability aspect, only the time to deliver.
Government software, hopefully like most any other software, is going to live a long time and therefore be maintained for a long time. To deliver best value for money we should be focussed on reducing maintenance costs, same as any software development team. Another problem is political. I get the early impression that the need for software is often politically driven. The “customers” (managers of various service deliver centric teams) need the software in production ASAP, so they can report to their director-general or minister. They don’t care about the long term costs of maintainability, and I daresay the politicians don’t either.
With that in mind, I do wonder what the “best” approach to software in the public service is. I’m of the opinion that good software development practices are good practices whether in the private or public sector and I’d like to, over the next 6 months, try to move the teams on to writing unit testable software that obeys best practices such as S.O.L.I.D. and the SRP and more. In fact, one of the key official responsibilities of my position is to evangelise, encourage, (and hopefully implement) industry best practices in the team.
