I’d like you to consider the analogy, “Good government is like good software.” But specifically, I want you to look at it from the software developer’s point of view.
SOFTWARE DEVELOPMENT
When I was in college, classes on computer programming were very focused on theory and fundamentals. Nobody got to learn how to create fancy windows-based applications until they understood the absolute basics of programming: how computer languages are “compiled” into a form that the computer can run, exactly what the processor chips and memory cards are doing when they run the program, and so on. You didn’t get to learn “design patterns” until you understood “processor interrupts” (the computer people reading this will understand these terms).
As a result, a lot of new college graduates would emerge into the world with a very ideological view of what computer programs should be like. They should be efficient! They should be clean! They should be optimized! There should not be a single line of code–a single bit or byte–more in a program than what is absolutely needed.
I’ve been in a position to interview people like this for jobs, and to see how they operate when they are hired. The reality is, they need to let go of this way of looking at programming pretty quickly, or they fail. The most “efficient” code usually breaks when real people use it, and the time it takes to design it is usually weeks longer (at least!) than any business manager is willing to wait to see results.
Why would “efficient” code break when real people use it?
Let’s think about a simple order form as an example. The absolute simplest form is one that assumes that the user enters in all of the needed information (e.g. name, address, credit card number) in the correct place and then hits “submit” with no problems. That will be the most efficient computer program, from a design perspective: it will have the fewest lines of code.
But what if a person accidentally leaves something blank? If you want an order form that will catch that, and maybe pop up a little message saying, “Please fill this in, it seems to be blank!” then that will require more lines of code. If you want an order form that will check to make sure that the credit card number is actually in the valid format of a credit card number, that is even more lines of code. If you want a form that will allow people to fill out the form partially, accidentally close their browser, and come back to it later and keep the information that they filled in earlier, then that is even more lines of code.
The more you want your program to be resilient to mistakes, the more lines of code you need. The more user-friendly you want the form to be, the more lines of code you need. If your goal is for your customer to have the best possible user experience, no matter how stupid they are and how much of a spazz they might be, then that will take many, many lines of code.
Plus, even our little order form also has to be connected to other online services and systems. If it checks to validate the credit card when the user presses submit, then what happens if (somehow, for some reason) it is not able to communicate with the computer that does the validation? Does the thing produce an error? Does it try again? Does it save the user’s information, or do one of those super-frustrating things where everything is blanked out and the user has to start over?
The more you want to protect your user from experiencing problems, the more lines of code you need.
Of course, there is an upper limit. In the end, a program can get so big and cumbersome that it actually take really long to load… and then you have destroyed the user experience again. So there are inherent limits on how big a program can get.
However, the longer Mr. College Grad works in the private sector, the more he will realize that you can’t just say “screw you” your customers. You can’t just assume that the other systems that you program has to communicate with will be available all of the time. Even if they are available, you can’t assume they will always return information in the correct format. Between the customer’s input and interaction with other systems, there are literally hundreds of things that can go wrong with even the simplest computer program.
And if a customer complains that their order didn’t go through, and you are called into your boss’s office, what will you say?
“Well, he filled out the form wrong!” This will get you no kudos from your boss. In the corporate world, the correct answer is never “The customer filled out the form wrong”. In the corporate world, the correct answer is, “I didn’t program in enough controls to prevent the customer from making that mistake.”
That is really the fundamental test of “good software” in the real world. It is not “efficiency of the code”, per se. The test of good software in the real world is usability, user-friendliness, and the ability of the software to recover from errors and mistakes and problems.
GOVERNMENT
A lot of young people, and people new to politics, think about government in a very ideological way. They decide that the best government is the smallest government, because what could be better than efficiency? In a way, these people are like the shiny new software engineering graduates right out of college. They call themselves libertarians.
But the problem that they face is similar to the problem faced by the software engineering grad who gets hired at his first company: in the real world, people don’t always behave the way that they should. People don’t input the right things, people don’t read instructions. And the world isn’t always put together the way that it should be. This is true in life, just as it is in computer programs.
So the smallest, libertarian government is sort of like the “most efficient computer program”… it usually breaks when real people use it.
Libertarianism breaks because people don’t always have multiple economic options to choose from. It breaks when employers hire and fire and give pay increases based on favoritism or prejudice instead of merit. It breaks when monopolies, or “effective local monopolies” form. It breaks when the labor force is out of balance with the job market. It breaks for product lines that give rise to increasing, instead of decreasing, marginal returns. It breaks under any number of situations.
What do libertarians say when these points are made? Effectively, libertarians are the computer programmers who say: “Screw the customer if he doesn’t use the program correctly. It’s his fault, he didn’t provide the correct inputs.”
But in the real world, that answer doesn’t fly.
A good government, like good software, isn’t judged based on efficiency alone. Sure: efficiency is a factor. But just as important (if not more important) is how the government handles the fact that things go wrong. People make decisions they shouldn’t, products don’t work the way they should, employers that don’t make the decisions they should, and so on. There are all kinds of things that can produce errors, and all kinds of assumptions that can “fail” in an economy.
And a government that cannot provide a “good user experience” in these situations is a government that is broken.
Good government is like good software: when the user doesn’t do what he should, the correct answer is never “well, too bad”. Software developers get fired for taking that attitude. And so should politicians.
