There are only a handful of books which I read in one go without stopping. 37 Signal’s “Getting Real” is one of them. Seth Godin put down some of the time consuming and heavy processes away from software development and calling you to get real by turning into the real problems that you have now! What he said is totally correct for small to medium companies and maybe even for some large companies to. But, what if you are developing software in a government agency and affecting the millions of people with the components that you developed. This turns your job into a mission critical state like a piece of software running in a pacemaker because human life is the subject of this software.
I am doing software development for about 10 years now and worked in private sector and government agencies where the heavy bureaucratic methodologies applied for the sake of complying with rules, regulations, law and public enforcement. You do analysis and design on a project and government comes along amends the law and you need to do those analysis and design sessions all over again. Endless meetings, hours of brainstorming, UML diagrams on the white board, everything is recorded. It has to be because the software is about the government and managing the public affairs, the whole taxation system, a social security system or a child support system. A simple mistake may lead to loose reputation, money, time and increases expenses. If you were the head of a government agency, can you afford a mistake like this? Can you afford to loose the trust that the public had built upon you?
As I said before in my blog Agile Software Development processes are just not applicable to government agencies where the software development process deals with millions of people and endless dependencies which are internal and external. Scott W. Ambler is also thinking the same in an article that I read quite a long time ago (sorry, no link) in the Software Development magazine. You can not make it light weight, you can not start from screens. You have to think and document about the workflow, use cases, database design, performance, formal tests, sign-offs, deployment schedules, deployment procedures, internal and external interfaces, communication formats etc.
Don’t get me wrong, I am always a good believer of Agile and Extreme methodologies. I am trying to implement at least some bits and pieces where applicable in my day to day work. I saw benefits of those so far. There are other areas which you have to follow strict procedures; they are easy once you learn how to implement them.
When I have started with a large government organisation in the past, they gave me a thick folder to read as an introduction kit and more was on the intranet. I had to develop software based on organisational standards, fill and raise correct forms so that other teams can do their job properly. If you do not follow the correct procedure to do your job; it may blow on you and it would blow loud. Of course there are also quick ways of releasing an emergency fix for an application if there are enough customers affected.
When you try to make a change on a piece of software, you have to do an impact analysis to see who is affected. You have to define what are the cost and benefits of this change, how many people you need, budget, time, tasks, schedules and collaboration and communication with other teams. You have to do it for protecting the public, agency, and dependent software components. The dependencies which are affected are so branched that even sometimes you don’t hear from them till you deploy into production.
There are also contractors, 3rd party companies and products and different people with their different tools. They all communicate and collaborate during the software development process. The operation is big enough that if you are not talking the same language with them, you just can’t communicate. For example for the deployment of your application, you need to raise an internal “Request for Change” which creates a “CAMS” record with a reference to your RFC on the contractor companies system and processed. Yes, it is bureaucratic but also easily traceable. You have a CAMS number and an RFC number and you can track the progress like you are tracking a DHL shipment.
It is also crucial that every step of the software development process is defined, implemented and managed. This gives the agency the possibility to comply with CMMI.
You can not reduce the features to release often and early. All features are tightly connected to business rules and use cases. The unnecessary clutter had already been removed during the analysis phase. I remember on one project we used to have 64 use cases initially and reduced to 13 in total.
There is also an independent office that checks the validity and compliability of the documentation and these guys do random checks on projects without a warning. If you get caught without enough documentation or missing pieces in your procedures and processes, you will be punished (though I do not know what the details of this punishment are).
There is also a time constraint. You have to finish the software and deploy into production when the corresponding law has got the royal ascent.
Chapter 11 talks about the functional Specifications and their uselessness. I really would like to get Seth Godin and my MSE teacher Clive Boughton at ANU face to face and start an argument about this very subject. If Seth Godin is right, everything I have learnt in MSE program is a pack of lies but I doubt it. May be functional specifications are not written as they should be considering all those agile and extreme methodologies influencing software developers. We (software developers) are already tired of writing a lot of documentation and when a methodology comes along talking about light weight paper work, we all cheered HURRAAAY. But when the dust blown away after a while, you realise that there is no documentation left what so ever and the head developer left the company for greener grass. <sarcastic voice> So what are you going to do now? </sarcastic voice>. There are CMMI methodologies which you can select with Team Foundation Server when you are creating a project and tell you that you need to create certain documentation to move on. These are necessary to estimate the size, budget, work break structure, schedule etc. of the project. You can even go deep and produce a preliminary Data Flow Diagram in the beginning of the project to understand the size and complexity of the project.
I believe whatever method you are following with your software development project, if you truly follow it through the last details of it; success will be yours at the end. But if you try to cut corners here and there, things will start to stink and once you smell this stench it will be too late.
As a conclusion, keep in mind that not all methodologies are applicable to your workplace. You should always on the look out for new information about new methods but should also comply with standards of your organisation. If it is a large project or operation with lots of contractor companies and workers; having a good documentation and written procedures will always straighten out the ambiguities.
