I see that the FBI Virtual Case File project continues to bleed money and shows little sign of stopping. I’ll bet a shiny new dime that when all is said and done the project will cost upwards of a $1 billion without much in the way of deliverables.
I’ll stick to the analysis I made more than 18 months ago. Today’s largescale computer applications should be thought of in terms of an evolutionary approach with worthwhile, usable deliverables all along the way rather than as a shrinkwrapped product delivered at the end of some unforeseeably long period. If federal government funding procedures can’t handle such an approach, that means that the federal government can’t tackle such applications regardless of need.
It’s the eternal conflict between the needs of software development and the needs of bureaucracy, and it is not going away any time soon.
See, bureaucracies need predictability, chains of responsibility (someone to praise/blame) and thus of accountability, raw material for reports to uninvolved managers and funders, making use of in-place personnel of widely-differing experience and capability, and constant buy-in from stakeholders. This leads to heavyweight development methadologies akin to the Unified Process. It is important to keep in mind that large companies are no less bureaucracies than are governments and large non-profits, and the same problems drive the same solutions. The UP is nothing more than a software development process tailored to the needs of large organizations.
At every stage, a UP-based development efforts is focused on documentation, paralysis through analysis, repeatability, reproducability, and predictability. This is massively inefficient, but does have the benefit of meeting the needs of a bureaucracy. How inefficient? Something that had taken over two years in a particular client, and was still not done, was done in two months by two frustrated programmers in their off time. Everyone liked their solution, so it was used to replace the long-running project’s output. The documentation, seeking of buy-in and approval and testing processes then consumed another year before the software went into production.
The alternative, which was created for rapid application development such as that used in small companies or in most open source software, is agile development. Agile development relies on high-quality programmers, designers and architects with a focused goal. Agile development provides minimal documentation, minimal tie-ins with groups not involved in the immediate software development effort, rapid turnaround (some projects release new builds weekly, most monthly) and almost no accountability. But it tends to produce great software, particularly because the approach is highly iterative. Rather than testing once at the end in a big cycle, testing is constant, and feedback is nearly immediately incorporated into the next revision. Rather than spending months in meetings explaining everything that is going to be done, then more months redoing it when people actually see it and realize that they didn’t want what they thought they did, agile development projects show people the product as it is, and then fix the problems early.
The problem is that agile development meets none of the needs of a bureaucracy. And as such, it is essentially impossible for any large organization to use agile development, despite its lower costs and better results in terms of actual software. It is simply not possible for a large organization to throw money out without being able to precisely account for it in advance. The managers who did this would be fired, because bureaucracies are not about results, but process.
In other words, why should we expect the government to be better at software development than they are at anything else?
Years ago I got a certification in a methodology from Arthur Anderson called Method/1. At the end of the class I spoke with the instructor and pointed out that there were no procedures in the methodology for ensuring that the project satisfied the original requirements or came in on time and within budget (but there were plenty of controls that helped you figure out retrospectively where you’d gone wrong). His response: “Maybe no one will noticeâ€.