Tuesday, April 19

Is there a traffic engineer in the house? Stuck at the intersection of government and the Mass Age

"Pundita, I know you want to move on to discuss other topics, but I think your Mexico posts brought up issues that go beyond the illegal immigrant problem. I'm getting the feeling the American and Mexican governments and maybe all governments today are stuck at the intersection of mental gridlock.

I thought you and your readers would be interested to know about a voluntary program developed by the Mexican federal and state governments that's scheduled to start at the end of April.

The program puts deported Mexicans to work in Piedras Negras (Coahuila State), just across the Rio Grande from Eagle Pass, TX. The Mexicans will be paid $180 to go through a month's training then put to work in for-export assembly factories.

This Mexican program is a completely different approach than the US voluntary repatriation pilot program you mentioned, whereby deported Mexicans are transported at US expense back to their point of origin, which is usually deep inside Mexico.

After reading your posts on Mexico, I seriously question whether either program is anything more than a bandage. The Mexican program is only set up to provide about 700 jobs to Mexicans willing to stay on the Mexican side of the border, but about 50,000 Mexicans are deported just through Eagle Pass every year.

It's the same with the US repatriation program. It is only set up to handle a few thousand [deportees]. If they were willing to travel all that way to get into America, there's no guarantee they won't make the journey again as soon as they're "repatriated."

Neither approach breaks down the problem, as you did, into different categories of border crossings--migrants, commuters [work in US, live in Mexico], and temporary ['guest'] workers who [live and work in the US and] plan to return to Mexico as soon as they've earned a target amount of money. Their approach ignores the distinctions, so they're like a doctor treating symptoms instead of the illness.
[Signed] Tony in Dallas"

Dear Tony:

You need to realize that governments are not really set up to solve problems but to manage them. The conflict is that the Age of the Masses--the mega-populations--has created situations for civilized societies that demand engineering solutions. The obstacle is that the engineering problem-solvers who work in government are usually at the bottom of a chain of command.

It's virtually impossible to break the chain from within, in a democratic government. So that's an added obstacle to problem solving, which came to the fore in America in the wake of 9/11. I recall published interviews with generals and intel analysts who said flatly that desperately needed solutions to certain US defense problems could only come after the second catastrophic attack.

They were implying that problem-solving of a certain order runs counter to the negotiations and compromise that support democratic government. A second catastrophic attack, which likely would temporarily institute martial law, would allow for greater latitude in solving problems outside the matrix of compromise and the muck of red tape.

So what we have here is a dilemma for modern civilization. Our numbers have created problems that can't effectively be managed or contained. They have to be solved. But implementing the solution can offend any number of factions within a democratic government.

This brings forth the Half-a-Bridge model of problem-solving. You arrive at a solution that will please diplomats and heads of state, a certain number of constituents and their elected representatives and lobbyists. If the solution is not the right one--well, it's a right solution based on the society's priorities.

Yet to return to the other side of the dilemma, these days a half a bridge doesn't cut it in many circumstances.

The time-honored way around the dilemma rests on the happy fact that humans aren't born idiots. If the problem gets so bad that it's clearly obvious a real solution is necessary, most people are willing to bite the bullet, at least temporarily. They will find someone who actually knows how to solve the problem, and allow him to cut through as much red tape and political bickering as necessary to get the job done right.

Here we come to a snag. If you don't have expert knowledge, it's unlikely you can recognize when a problem is at the Red Flag stage. This is the snag that's tripping up governments at this time in history. In many cases they don't recognize a system failure until it's too late for problem-solving; it's just enough time for triage if they're lucky.

The good news is that there's a very loosely organized discipline that's sprung up to preempt this snag--and just in the nick of time for the human race, I might add. The discipline is large scale systems design. I learned about this field of endeavor from Guru David, who made his first appearance in Pundita's essays as The Guru--the computer scientist who was the go-to guy for computer systems engineers who were stumped.

They were stumped a lot because they had the job of computerizing, from the ground up, one of the largest utilities in the world. It's hard for young people to imagine but there was a time when phone, electric, water processing facilities, etc. were not computerized. The computer systems engineers who made it happen wrote a new chapter in human history.

But just because they were out there at the edge of No More Knowledge--with no referents, no guideposts for how to proceed--they had to cast around for problem-solving ideas that were from outside the field of computers.

That's why I never saw Guru David carrying a book on computing; he was always reading stuff like biology, astrophysics, history, city planning, and bridge and tunnel design. So one day I asked him: Just exactly what do you do at your work?

That is how I learned that you can look at many things as a large scale system and from there, draw analogies between phenomena that are as diverse as the solar system, living organisms, a bridge, a city, and human societies.

Systems engineering greatly predates computing; the military and logistical engineers who moved armies from Point A to Point B during ancient times were systems thinkers. But by the 20th Century, systems engineers from many different fields were beginning to talk with each other about the similarity of certain kinds of problems they repeatedly encountered in their work.

Thus, the highly abstract concept of systems engineering, as a discipline in itself, began to form. This was given a boost by the computer revolution and the kind of problem-solving that formed Guru David's daily work grind.

The field is still in its infancy, but it holds the key to good governing in the Age of the Masses. This is because of the First Law of large scale systems design, which I pried out of Guru David by asking the clever question, "Is there a first law of large scale systems design?"

"Yes. The first law is that the more successful the system you create, the quicker it will break down."

This is the way of gurus. They mean to always prod you to another question.

How can you call a system successful if it's bound to break down?

"Think it through," The Guru replied patiently. If you build a bridge that efficiently carries traffic to a hub, then more and more people will use the bridge. The more use the bridge receives, the more strain on the bridge's structure, which means it will break down faster than a bridge that is not as successful at moving people to the hub."

Success begets failure. A paradox, to be sure.

"Not really, if you know that success begets failure. Because then you can build monitors and fail-safes into the system that take the First Law into account. For example, you inspect the successful bridge more often than the other one, make repairs much sooner than you would for a bridge that carries less traffic, and build alternate routes that put less strain on the successful bridge."

"Is the solution to the paradox the secret of the universe?" I asked in wonder.

"I don't know," replied The Guru. "But it sure as hell is the secret to preventing switching procedures from crashing."

To be continued.

No comments: