Big Idea 2014: How to Fix Washington's Approach to Tech

This post is part of a series in which LinkedIn Influencers pick one big idea that will shape 2014. See all the ideas here.

Much of the business of Washington is based on getting info around, much of the good news has not been reported, and I'd like to get the word out to make things better. This is the short, oversimplified version, based on 37 years of direct observation in both private and public sectors.

This is mostly about doing software based on actually listening to people and then acting on feedback, with a focus on the "ground truth" and what we can learn from that.

I think it was 1969 when some guys at Bell Labs started inventing something called Unix. It was a simple, very effective operating system, which could be ported to most any computer, since the source code could be checked out by outsiders, then adapted. It was in the spirit of what we now call "open source," but the code was AT&T proprietary, limiting its use. Key to its effectiveness was that it was built in modest increments, by people who'd use it, both at Bell Labs and at the universities and labs who built Internet tech.

Note those elements: Built with real humility, talking to people, piece by piece.

Back then, software was most often developed starting with requirements or specifications docs. These were written by managers or people in marketing, the popular kids, who didn't so much as talk to the people who'd run the software.

Once the docs were written, they tossed it to the people who'd write the code.

If the software actually got developed, it would frequently be late, over budget, and sometimes bought by no one except people who had to. (That's like a lot of Federal software projects.)

In Washington, this is called the "waterfall" approach, since the docs are kind of tossed over some barrier which limits the ability of coders to talk to people, and which meant the software was frequently built as a big, complex monolith.

I saw this approach used to develop the first operating system for the IBM Series/1 minicomputer, great hardware, in the late seventies. Whenever I asked why the software was so hard to use, I was explicitly told by the developers that usability wasn't a requirement. (I'm not making this up.)

Bell Labs asked us about porting Unix to the S/1, and my recommendation is that we could do better, but why fix what's not broken?

Turns out that a modest, maverick effort at IBM Research resulted in S/1 Event Driven Executive, which I feel was much better than the official product. For the matter, two versions of Unix were built for the S/1, both too late.Otherwise, the history of the whole industry could be different.

Years later, Linus Torvalds figured that Unix was pretty good but too proprietary, so he started building what's now called Linux. It's pretty much a Unix clone, but it's open source in the sense that anyone can build stuff on it.

(Special props to Linus, who initiated this global, grassroots effort. Linus, like Jimmy Wales and Craig Newmark, is not an Internet Billionaire.)

That worked in a really big way, and much of the world runs on Linux, not only servers but our phones. Specifically, the Android operating system is a tight version of Linux, and it runs on hundreds of millions of phones. Even though developed in a large corporate environment, Google, it's a pretty modest effort, based on what people need, rather than the imagination of the popular kids.

For the most part, government software is done using the waterfall approach, in isolation from the people who'd use it, even as much of private industry has moved on. However, there have been efforts which go against that grain.

Long ago, clinicians at the Department of Veterans Affairs realized they needed a really good health records system. Without permission, they built something called VistA, built by the people who use it, ground up. It's perhaps one of the largest, and most effective health records systems around. No waterfall requirements, just a very modest approach.

Now, Veterans Affairs got the Veterans Benefits Management System, VBMS, just in recent months. It hasn't been reported, but the piles of paper you see at VA offices has been disappearing dramatically after they were scanned in. Vets' claims are just starting to get processed this way, and it looks good so far. We need to get Vets Service Orgs like the American Legion, Vets of Foreign Wars, and Disabled American Vets directly involved, via the Stakeholder Enterprise Portal, or vendor software via Digits to Digits.

VBMS development involved a lot of waterfall stuff, but much more recently, VA people are actually directly listening to people on that and acting on that. If vets, VSOs, or VA workers find a problem or have a suggestion, they contact contact actual humans to get stuff done.

Terminology: the antithesis of the waterfall approach is usually called "agile software development." I'm not very smart, and the version of it that I've practiced is this:

repeat forever:

• listen to people
• do stuff based on that

Please permit me to call that "agile"; seriously, I'm kinda simple-minded, that works for me.

(Seriously, people can contact for specifics. I'll act in my capacity as the official VA "nerd-in-residence", hold me to that. email [email protected])

So, here's the deal:

• small, modest efforts by programmers get stuff done, they can ask for forgiveness later.
• listen to the people who use the system.
• even systems started by the waterfall approach can become much more agile, with commitment from the boss.
• open source approaches get stuff done, often a lot better than proprietary approaches. Can cost less, get done faster, possibly more reliable and secure.

Programmers who get stuff done this way, well, we're nerds. The alternative to the Federal government's waterfall approach to software development? Get the popular kids, for the most part, out of the way, and let the nerds get stuff done.

Photo: AFP/Getty Images