And four co-workers--two I've been working with daily of late, and two others I'd worked with on several projects--chose yesterday to retire. A day full of good-byes....

This sort of day always sets me to thinking about my own retirement. Not yet. But I can see the end.

A substantial body of research indicates that private enterprise is inherently efficient. The people who wrote that research appear to work at think tanks, however, not private enterprises.

Anyone who has worked in a private enterprise knows what really goes on there. In any enterprise of more than a few dozen people, bureaucratic barriers and pockets of unproductivity crop up and stay around for long periods of time. A bumbling but politically astute manager can hire incompetent staff and maintain a whole department of dead weight, dragging down the efforts of others. Companies are irrational entities: they refuse to acknowledge errors promptly and pour good money after bad.

In short, all the failings attributed to government happen in private enterprises too. These failings are a fixture of human nature and organizational dynamics.

Andy Oram/Getting Universal Service to Work

Every now and then Andy Oram produces something really interesting.  This long essay is mainly about how to make universal service happen (not just broadband, though that's the main focus), but it touches on a whole lot of other topics as well; they include bureaucratic inertia, creative public servants, and the impact on policy of special interests.  And there's some discussion of unintended consequences.

Well worth your time.

It's not often I feel sympathy for Scott Adams' idiot Pointy Haired Boss, so yesterday's edition deserves a comment.

Every non-trivial project, including many which don't involve programming in any sense, eventually reaches this point.  Rands talks about the issue; so does Joe Bork. (Edit 11/6/07: Here's Eric Nehrlich of Fog Creek making the same point.) Of course we'd prefer to build a perfect process, but there are competing concerns.  Eventually, you must move the loose ends to Phase II, or you'll never complete the project.  One of the manager's jobs is to recognize the necessities/ expectations/ intentions driving the project, and to find the balance point.  The resulting conversation (more likely, meeting) will sound pretty much like the May 4 strip.

The last panel's right, too.  Applying appropriate labels is a fair part of the job.  Pointy's usual problem is that he gets this wrong.

Three panels just aren't enough to carry the argument--you have to already know about Pointy for the joke to make sense.  If Adams had been building to this strip for a week--showing that the project really had spun out of control, and that Pointy really doesn't know how to balance this stuff--I'd like it a lot better. 

Or perhaps I just don't understand.

In my experience, absolutely no bureaucractic entity (yuck, dabbler--don't talk like that!) is truly created from the ground up. There's always an organizational context, a political context, legacy data, system integration issues, staffing issues--and it's impossible (and rarely desirable) to remove those contexts and continuities from the new organization's environment. On the other hand, the usual object is to move the organizational focus, which is nearly always gainful (and painful). This article explores how those things played on in the Homeland Security context; the scale's different from mine, but the issues are familiar. Looking forward to Todd's followup article....

Link courtesy of CIO Magazine's KM Newsletter.

The Army had trained more DSTE operators than there were empty slots, so we were TDPFO in the desert, waiting for the installation teams to build the places we'd work.  We had some notion of the pending construction, and we were being permitted to "bid" on specific stations.  (That worked like this:  As each installation was completed, the TDPFO GI who'd been longest at Huachuca was asked if he wanted to go there; they worked down the seniority list until the slots were filled.  If this method didn't fill the staff, the most senior folks "won" the assignment, regardless of preference.  Getting what you wanted had some risks, and involved balancing what you knew about construction progress with your actual wishes, but it worked out well for most of us.  In my case, London came up the day after I accepted an assignment to the San Francisco area.  I might have lived a different life.)  (No regrets, he wistfully claims.)

I spent three months at Huachuca, which was pretty typical.  Many of the folks I attended DSTE classes with ended up in either LA or Seattle, in the same command as my SF assignment, and several of us moved together to Pleiku at the end of the year.

Pepys was a delightful diarist, and worth reading for all sorts of reasons. One which (naturally) appeals to me is that he was a professional bureaucrat in a time when bureaucracies were new to European government. Bureaus were small, too; they seem to have run the Royal Navy with just a handful of clerks. (I seem to be ignoring the admirals....) Part of the fun when I read Pepys is watching him feel his way around the organizational issues. Not to mention office politics. And real politics.

At least I don't have the King of England watching over my shoulder....

Phil Gyford's Pepys Diary website posts today's entry each day, blog-style, 343 years to the day after they were written. A splendid application of modern technology, if you ask me.

Several RSS feeds are available from this page.

To understand this story, you need to know that DSTE's a computer terminal; in this context, it's basically a fast teletype. I'll tell you more about it some other day.

A typical workday at the Pleiku Army Communications Center

An Army headquarters has similarities to other offices: People spend the day doing whatever they do. At the end of the day, they clear off their desk and pass the day's work to the next desk. If that next desk was not in Pleiku, it landed in our CommCenter on its way around the world. As you might guess, we got busy around supper time, as both outgoing and incoming message traffic tended to pick up around 1530 Vietnam time; the rush would queue up, and would typically end (in both directions) several hours later.

The Day I Screwed Things Up

On the day after my twenty-second birthday, my Trick Chief (TC) left me in charge of the DSTE. Sometime that day, our sister operation in Nha Trang went down with equipment difficulties; since they were off line, the network transferred their traffic (which basically duplicated ours) to our station. (Our direct teletype connection with the Nha Trang CommCenter was the backup circuit for both stations.) This doubled the workload at the DSTE, and radically increased the relay workload in the teletype room. We adjusted assignments, and I spent several hours tearing paper tape and deciding whether it was for PKU, or NHA.

I'd been in-country a month, and this was the first day I'd worked DSTE alone. By the time the shift changed, I was exhausted. Shortly before shift change, things improved somewhat: Nha Trang's DSTE came back on-line. Since DSTE was far faster than the teletype line, we stopped the relay operation and someone returned the tapes to me. I slapped 'em in DSTE, & was finishing the cleanup just as the night trick arrived. I briefed my relief on the situation, went back to the barracks, and fell asleep.

TC woke me up, and chewed me out: Seems that as the traffic stopped, twenty-eight error messages came through. I'd forgotten that several of the messages originated on punch cards, not paper tape, and thus had improper headers and footers for paper tape transmission. The night TC noticed; he woke the Chief Warrant Officer to report it. The CWO woke my TC, who woke me. After some discussion, TC dragged me to the CommCenter, where I re-sent the messages with proper headers and footers. Then he bought me a drink at the NCO club and we returned to bed....

Truth told, neither the CWO nor my TC cared a lot about the errors, except they looked bad in our reports. Both superiors knew I'd made one error and repeated it fourteen times (the double-count was a reporting artifact). They also knew that it would show as 28 errors on the computerized reports, and (near as any of us could tell) those reports were the main method Saigon used to evaluate CommCenter operations. They issued performance rankings based on those counts....You need to understand my 28 errors. All messages were technically freeform (I'm ignoring some human-readable formatting), except that they had standard headers and footers. The header was formatted to fit a Hollerith card. The first 80 characters had to fit a specific format, and perhaps a dozen of those characters had to meet accuracy checks. End of Message was indicated by one or four "N's", depending on the medium used to create the message.

• My first error for each message was generated on the second character in the header: It was "C" (for CARD), but since I was using a TAPE drive to (re)send the message it should have been "T".
• I generated a second error on each message for an incorrect End of Message indicator: EOM for card-generated messages was a single "N", while tapes were expected to end "NNNN".

Side note: The system's programmers had actually anticipated this error. Since my messages were marked as flash (high) priority, they were delivered to NHA; the error messages were more like courtesy reminders than real errors. Didn't show that way on the reports, though.

At the end of every month, USARV HQ in Long Binh would send all the Vietnam CommCenters a report ranking them by error rate. Presumably, communications careers rode on these reports, as we received no other messages which compared the CommCenters.This was stupid. Basically, the brass was using the 80-character header as a proxy for the message, and judging the quality of our messages by the error rates of our message headers. This, of course, made checking the header a significant part of my job (32 years later I can still read Baudot code, though I can no longer do so quickly).

But that wasn't a good proxy. After traffic dropped off, night shift would spend a couple hours handling problem messages received from other CommCenters. These all had good headers. But it was clear that specific CommCenters couldn't get the freeform part of the message right. We saw no evidence that headquarters attempted to measure that part of our communications system.

The computer can count it. Why use a method which requires analysis of real messages?

It was a bad measure in another way. Except for one CommCenter, we all had error rates around one percent. On a bad month, someone would approach 1.5 percent. Except that Long Binh--headquarters, and by far the busiest message generator--was evidently exempt, and lived with a 3% error rate.

I'd have told this story anyway, but it's partially a response to a note by David Weinberger/Joho the Blog.

Beware what you measure.

I'm still here....