Sunday, November 17, 2013

Tips for Software Innovators Inside the Federal Government

This essay was first published at the Code for America Blog.


Tips for Software Innovators Inside the Federal Government

  1. Change the game through prototypes,
  2. Be a samurai: a loyal hacker,
  3. Be fast rather than good,
  4. Stand on the shoulders of giants,
  5. Scrape, don’t bow, and
  6. Be prepared to work outside the system.
1: Change the game through prototypes
A picture is worth a thousand words and a working prototype is worth a million. The federal government is used to suits coming in and talking about how great a system they are proposing to build will be two years from now if they are given millions of dollars to build it.

Shatter that paradigm by showing up with a working prototype, and talk about how great it will be if you get their cooperation in polishing it.

2: Be a samurai: a loyal hacker
The federal government has outsourced its technical brain and understaffed its technical know-how. It is not uncommon for one technically savvy person to be in charge of overseeing millions of dollars of labor without a staff. In short, the contractors have the administrators outnumbered about 30 to one. This is a recipe for chaos and confusion, and the result is terrible performance of contracts in many cases.

Say to the administrators: “I am a hacker, and I have no outside interests or loyalties. I am an expert who can’t be bluffed or intimidated or deceived. I will be your bodyguard, your gallowglass, your samurai. You can rely on me for brutally honest technical advice. With me at your side you will be able to negotiate a better contract and stay more in control.”

3: Be fast rather than good
Scientists need to study what happens inside government buildings, because I’m quite sure all processes are five times slower inside the federal government. Paper falls to the ground more slowly. When you switch on a light, it takes a while for it to reach the corners of the room. Getting a computer takes six weeks. Getting an Authority to Operate takes three months.

The government needs people with superpowers who are not affected by this timespace anomaly. Things that normally take a year need to be well underway within a week and ready for evaluation within a month.

Why? Because this is the best way to reduce risk. To make sure a two-year-long project matches the needs for which it was intended one must strive utterly to get as far as possible in the first month. In order to do that, programmers must be prepared to be sloppy and lock their inner perfectionists in the bathroom for a while.

An engineer who can build a prototype in a month can change the consciousness of an entire organization faster than the government can get a contract written to do the work. The methodologies that have been developed in the last 20 years to develop software quickly really work, and they work even better within government where speed is desperately needed. These are named Agile Methodologies, Extreme Programming, Lean Startup, and so on ad nauseum. Every few years the basic concepts are tuned a little and renamed, but the principle remains the same: learning something real right now is more important than fantasizing about something big a year from now. As Kent Beck has taught us, “You go fast by taking babysteps as rapidly as you possibly can.”
Demand the same speed and transparency from contractors that you demand from yourself.

4: Stand on the shoulders of giants
America invented the “Free as in Freedom” software movement. There is a silent army of intellectuals constantly adding to freely available software. Historians a century from now will look upon it as a great gift that the USA gave to the whole world.

The continuing explosion of off-the-shelf software capabilities is so tremendous that a software engineer now must think not so much about writing programs but about joining programs together. No one person can keep up with all of these capabilities. I love programming, but it is my duty not to program but rather to spend most of my time investigating what others have programmed in order to not reinvent the wheel.

5: Scrape, don’t bow
The biosphere of government software systems is a coral reef, each system built on the grotesquely shaped skeleton of its ancestors. These systems have inertia: users, rules, regulations, entry points, touch points, system interactions. Rather than try to change them, accept that whatever you build will have to be bolted on to the existing reef with as little disturbance as possible. By scraping existing websites, or by using extract-transfer-load tools, you can make something wonderful and beautiful even if what lies beneath it is ugly.

6: Be prepared to work outside the system
The government is risk-averse and highly responsive to outside pressure. It fears embarrassment. It loves praise.

If you can find one example of an agency doing something, it is much easier to convince other agencies to follow that example. Just as entrepreneurs must be prepared to go hat-in-hand to many different potential investors, be prepared to look for champions of change outside your own circle.

Finally, when you encounter resistance, ask yourself, “If I were not a government employee, what could I do to solve this problem?” Citizens want to help. Find them and utilize them to expand the bounds of possibility.

--Robert L. Read

Friday, July 5, 2013

PIFAM on hold because I am a Presidential Innovation Fellow

I'm honored to announce that I have the chance to serve my country as a Presidential Innovation Fellow (PIF).  Note that the abbreviation (PIF) and the name of this blog (PIFAM) is pure coincidence.

http://www.whitehouse.gov/innovationfellows/round-2-fellows

I plan to work with extraordinary dedication to try to save the government money, so I'm afraid my other invention and innovation work will be placed on hold for the rest of this year.  In fact, I have been working here in DC for the last week, having left Austin and my wife and daughter to be most effective here in DC.

This blog has never had much readership, and few comments.  Although my time is limited for this year, I plan to return to it in 2014.  Until then I am of course able to respond to comments if there are any.

Tuesday, January 1, 2013

New Project: Parallel Markup

Dear Fellow Inventors,

Elliot and I have decided to postpone working on the Fresnel lens until warmer, sunnier weather here in Austin.

In the meantime, I intend to create a new project, which I call "Sparmark", a human readable system for parallel markup.

Parallel markup is the idea of NOT modifying a document with markup but rather creating a separate, parallel document to hold markup which essentially represents a transformation of the original document.  When I studied this field some years ago, the research for it was not terribly advanced, and I thought it was a field in which amateurs such as ourselves could make a significant contribution.

I believe Ted Nelson has been the biggest contributor to this field with his idea of Transclusion.  I found this paper: Embedded Markup Considered Harmful http://www.xml.com/pub/a/w3j/s3.nelson.html to be a particular compelling and cogent expression of the problem.

In this post on New Year's Day I can't put down all of my ideas about this, but here is a summary:

  • I think we should create an open-source project to create parallel markup standards and software tools that will make transclusion much easier.  I imagine Python to be a language particularly well-suited to this, although I have never used it. (My previous work on this was in LISP.)
  • We must focus on creating a forgiving and human-editable markup.  In particular, I intend to draw inspiration from the markup that human copy editors do with a pencil.  The fact that we must deal with electronic texts should not prevent us from learning from the analog standards that copy editors have developed over decades.  XML is a terrible failure because it focused on software tools rather than human use.
  • I'm going to go out on a limb and try to create some videos and other things to recruit others to be involved in this project.  This log is very lightly read.  I don't seem to be very good at affecting my fellow workers, but I intend to continue working on it.
Please contact me if you would like to help create a team to work on this project.