All of these integrated processes were disrupted when Object Oriented (OO) programming languages were introduced. In OO programming you create classes of objects with attributes and manipulate them to deliver the necessary functions (processing, storing, calculating, etc.). Each object can be changed independently of other objects in the code. In an OO application you don’t need to have everything mapped out. You can build out some framework and add to it as you learn more about what is to be constructed.

This advancement presented opportunities to developers to abandon the old methodologies and create new lightweight ones. In fact, that was one of the chief discussion topics when a group got together at a Utah ski lodge in February 2001. The connotation of calling it a “lightweight methodology” didn’t fly and they ended up going with “agile” when they issued their manifesto. It is kind of odd that it is called a manifesto, right? Only the Unabomber and crazy people issue manifestos, and at the time, more people thought they were crazy than not.

agile manifesto
For us government people doing IT, this change was of the magnitude of taking the earth and spinning it the other direction and turning it inside-out. Instead of the sun rising in the east and setting in the west  and rain/snow falling from the sky, it was the opposite. Many government agencies chose to continue in the waterfall tradition while using the new technology. I call this a WaterFail. It is worth taking each of these agile value propositions and considering it separately.

Individuals and interactions over processes and tools
This statement is the one most contrary to the waterfall SDLC because in waterfall, when you are done with requirements, you are fricking DONE with requirements. Similarly, when you are done with design, you are DONE with design. Going back to add or change requirements or design after you have left those phases is wrong, painful and costly. I used to make people sign the requirements document with a red pen, and I told them that it was actual blood.

In this clause the original manifesto people were saying, if we discover a new requirement when we are in design or in development, that is OK because it is more important to understand how people need or want to interface with the application than being responsive to the arbitrary waterfall process. The truth is that they were just recognizing learning, which is a natural part of any development process. When I describe something in the abstract, I’ll describe it the best I can. But when I see it on a screen, I can give more targeted feedback that improves the product. Waterfall doesn’t account for this type of feedback loop.

Working software over comprehensive documentation
As I mentioned already, object oriented programming was a disruptive influence on the industry. One of the most tangible ways this was felt was in the area of documentation. Remember the binders? We used to document every single thing, and a lot of things that were outside of our system or application. The list below is representative of what was required to use at an agency circa 2005.

agency circa 2005 chp 3
Some of these document deliverables would be 50-100 pages in length, but some of them would be hundreds of pages. I remember one functional requirements document (FRD) was front and back of two three-inch binders. That is a lot of paper. And contractors were happy to charge the government for the production of all that paper.

The typical duration for the government review of these deliverables was two weeks. We typically had two weeks to read and comment upon a 600-page document. So these crazy agile people are pushing against that. They were saying, “I don’t give a shit about your document, I only care if the application works the way I need it to.” This makes sense because what happens when I learn something new while I’m testing? If I want to implement that change, then I need to pull that change through all of the documentation I have already produced. So I need to update the FRD, DRD, SSP, SSS, DB Spec and any number of other documents. That is where the cost differential comes into play, and that is where a lot of companies make a lot of money. As a result, the cost and pain of pulling that change through all of these documents discourages people from making corrections and that is how we get software that doesn’t work.

Read More About
About
Demosthenes
Demosthenes
Demosthenes is a pseudonym for a senior Federal IT official.
Tags