Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

3 good ideas from government software projects

David Taber | Aug. 7, 2014
Yes, many of the worst examples of software projects come from the public sector. But good news doesn't necessarily make for good headlines. Here, then, are three positive lessons to be learned from government software projects.

Credit: VFS Digital Design via Flickr

If you've read any of my articles, you know that the agile practices I advocate are rarely even tried in government projects. How can the guys who popularized the Gantt Chart and the PERT diagram help modern software projects? Oh, and don't forget the folks behind

Well, as somebody smarter than me once said, "Wisdom is the ability to learn from people who are dumber than you." Here, then, are three software developments we can learn from the government.

Use Sunset Laws
The good government crowd advocates the automatic expiration of laws, particularly for civil and regulatory matters for which standards change over time. Without a sunset provision, inappropriate laws can only be removed via either an act of Congress or a Supreme Court decision. That's why local, state and federal law books are full of stuff that's obsolete and even silly.

The same thing happens in IT with nonperishable business rules and requirements lists. In any serious system rework, the good business analyst will find scads of business processes that are bloated, over-specified and designed to handle a situation that almost never occurs. These four-sigma events are better handled manually; automation will likely introduce more problems than it solves. A study by the Standish Group analyzing mainframe conversion projects nicely documented this phenomenon. Guess what? Ninety percent of the function points in the old code were no longer needed at all.

The lesson: For any significant software requirement, enforce an automatic expiration date that forces the users (or other enforcers) to start from scratch and re-justify the need. This is important because the only free lunch in software is avoiding the implementation of fake requirements.

If You Can't Write a Test, It's Not a Requirement
This lesson combines ideas that the Air Force Systems Command used (and may still use) to avoid wild-goose-chase requirements. In a waterfall world, it's common to see expansive documents that are supposed to specify every detail of the deliverable module or system.

In these tomes, though, it's easy for the authors to get lost in the writing and be blinded to ambiguities or even outright contradictions in the requirements. Forcing the requirements process to specify the exact conditions that constitute acceptability will reveal these problems.

Taken to the extreme, this discipline means that no executable code will be written until the test code is written and validated. This is practically the definition of the test-first or test-driven development method of extreme programming, but it can be applied equally to agile and the waterfall projects where it originated.


1  2  Next Page 

Sign up for Computerworld eNewsletters.