eXtreme Programming and Good Government

Kent Beck, the genius who discovered eXtreme Programming, from whence sprang all so-called Agile methodologies, can lead us to good government. 

Beck, a senior consultant in the 1990s, noticed that all big software development programs began and ended the same way in the days of waterfall. 

Massive Requirements:  Every project began with lots of highly paid people sitting in endless series of meetings aiming to document everything that a system must and should do and how.  The system didn’t exist yet, but this did not stop the binder builders.  The requirements were usually very wrong.  The stuff they “required” had no market, wouldn’t work, or contained self-contradicting statements, like “all numbers shall be represented with letters.” 

Massive Design:  Since the requirement rarely made any sense,  a most senior programmer who worked for the software vendor would attempt to draw pictures of what he thought the requirements meant.  Since the people who did the requiring had no idea what the engineer’s symbolism stood for, the engineers could convince the customers that their drawing were right.  This guaranteed a system the customer didn’t want, but it bought a lot of time.

Massive Hidden Development:  Development always began late because the first two steps always took twice as long as anyone thought they would.  But that’s okay—development will take twice as long as predicted, too. During this period, the customer might forget that the project was launched since the programmers and their work remained carefully hidden from view for months–sometimes years.

Massive Testing:  This is everyone’s favorite part.  After eight months of programming pictures that don’t mean anything to anyone into software system, the people who drew the pictures convince testers—who are usually very green programmers or wannabe programmers—that the software works exactly the way the customer wanted it to.  The testers then stare at their computers for four months, report bugs for everything they don’t personally like, and, finally, put their stamp of quality on the product.

User Acceptance Testing:  This is where the customer first sees the product—2 years after signing a contract.  During this phase, the client manager who agreed to let this particular company develop this particular system works closely with the vendor’s senior developers to craft a convincing argument.  This argument must demonstrate to executives in the client company that the manager didn’t throw away $2 million on a system that will never work.  That task is more daunging  because the software system was supposed to keep track of weather balloons everywhere in the world but it actually predicts the number of Powerball Lottery tickets that will sell given an estimated jackpot. 

Crunch Time:  After realizing that he’ll never convince his bosses that the vendor delivered is what the cliented wanted, the customer gathers two or three of his key people to “work out some issues” with the code.  These two or three people work along side four or five of the vendor’s best programmers and a tester.  This mixed team is co-located, and it works 18 hours a day for 2 months.  Instead of written requirements and esoteric drawings, the customer people tell the vendor people exactly what they want and how it should work.  The vendor people code it and demonstrate it as the customers look on. When it’s right, customer says, “Done.  Next.”  They work together on one or two things at a time until the system is sufficient for their needs.

Post-Mortem:  This is where Kent Beck (and everyone else who’s ever been part of a waterfall software development project) realize that 80 percent of the code that the customer accepted was written during the 2 month “crunch,” that 80 percent of the original requirements weren’t needed, and that 80 percent of the drawings were meaningless.  Smart people, like Beck, say, “You know what?  Next time we have 2 years to build software, lets skip right to the crunch time.”  Stupid people, like 90 percent of the organizations in the world, say, “Next time, we’ll spend more time gathering requirements and drawing pictures and testing so that we get it right.”

Lesson for Government

Jefferson, Madison, Franklin, Washington, et al, discovered the United States of America’s government the same way Beck discovered intelligent software development:  they observed what worked and did that.  They threw out all the stuff that didn’t work.  They accepted the fact that the smartest men in the country couldn’t run the country as well as the people could run themselves.  They admitted that the people would tell the government when they needed it to act, and that absent such a signal, the government must do nothing.

When Henry Paulson and Barack Obama tell us what government must do, they are like the requirement gatherers telling the programmers what the system must do.  They are probably wrong.  And if they’re right, they’re still wrong.  The people are smarter than their leaders. 

Technorati Tags: extreme programming,good government,kent beck,thomas jefferson