(My forty year career summary, in short, pithy increments, with a dollop of philosophy added for good measure...)

My first real job!

I began my professional career as an "Engineering Aide" with a research firm that was in the business of designing a new type of nuclear reactor.  It was the early 1970's, there was a recession, and I was just glad to have a job! My new boss asked me if I could "program computers".  I confidently said "Sure", remembering that I had taken a course in Fortran in my sophomore year at the University of California Berkeley three years earlier.  I had the good fortune to be mentored by a kindly Japanese woman whose name I have sadly long ago forgotten, and who spent the final two weeks of her tenure with the company bringing me up to speed as her replacement.  Pretty soon I was banging out code for the Seismic Core group, modeling the behavior of the reactor innards during an earthquake.  Heady stuff! We used Univac 1100-Series mainframes, submitting our job decks of punched Hollerith cards in metal trays that we lugged to the computer center submission window, filled out the job request form, and went back to our cubes to wait (hours, sometimes a day or so) before the printed results would be stuffed in our assigned cubbyhole.  Hopefully we did not make a simple coding mistake that required another submission before we even saw a result!  My fondest memory was taking our output, several inches of fan-fold printer paper, stretching it out along the long office corridor floors, using a marking pen to connect the X marks on the paper that represented the motion of the container vessel, and stepping back to admire our "graphical" handi-work!  Yes, it seems quaintly primitive, but what a great feeling that you were producing something that would become a real product!

Moving on...

Alas, events conspired against us (escalating costs and slipped schedules) that became an all-too-familiar theme as I moved from job to job in the industry.  I left for a company that was designing an ocean mining system to harvest minerals from the deep sea floor.  An enormous vacuum cleaner with a 15,000 foot hose, in effect.  And I got to play on a new state-of-the-art system called a "mini-computer" that actually allowed you to touch it, insert your program from a terminal screen, and get your results back "instantaneously".  This lovely beast was a VAX 11-780, built by Digital Equipment Corporation.  I still feel, 30 years on in my career, it was one of the best engineered computers ever built, and had one of the nicest operating systems, called VMS.  My job was to take engineering designs, sometimes in the form of scribbled yellow sheets, often in the form of “air diagrams”, and turn them into code.  The most challenging task was creating a hydrodynamic model of the slurry moving through the harvester and up the system of lift pipes, through the pumps, and up to the ship.  A few of the engineers took to sea to test the viability of the operation and brought back some samples.  Manganese nodules, it turns out, make decent paperweights!

I become a Defense Contractor

Deep-sea Mining turned out to suffer from the same perils as designing nuclear power plants, but soon after that program went bust I had transitioned to the world of Defense contracting.  It was the '80's, Reagan was our President, and a major military technology buildup was underway.  I was hired as a "Software Engineer", officially titled with all honors and accolades due to one in the august profession (long days, long nights, too much coffee and junk food), and got my first taste of leadership, as the head of a small team designing a flight simulation system for the Air Force.  I became familiar with ‘A’, ‘B’ and ‘C’ Specs, PDRs, CDRs, TRRs, and the acronym soup of Government contracting.  Meanwhile our custom graphics processor (the size of a small refrigerator) turned out to be a programmer’s worst nightmare – we were the manufacturer’s guinea pigs (sorry, I mean Beta-Testers) for sure!  But the system got delivered after many schedule ‘adjustments’ and over-run budgets.  We could actually claim success!

Headed for Mecca

From there I answered the siren song of that Defense Industry mecca, and moved to Washington D.C. with wife and two young children in tow, to work in the high palaces of government, mostly decrepit and cramped cubicles full to the rafters with equipment and documents, and the ubiquitous wall decorations (“You want that WHEN??”, “Pardon me, you must have mistaken me for someone who actually gives a crap”).  But I gained more insight into how systems were built, and actually got to manage a modest-sized program, based on a new Government-mandated computer language called Ada.  I was managing people and budgets, with plenty of help from my management chain, the contractor, and the Government!  We had a great team, it was great fun, and it was doomed.  Obsolete by the time it was designed.  Sound like a familiar theme?

Gaining Insight

I stayed in Mecca for many years, working on programs of all different scales.  Some fared better than others, usually the smaller ones.  As for the large ones, there were more failed systems than successful ones.  Programs that wound up costing two, five, ten times their original budget.  Systems that did a lot, but not everything they were contracted to do.  Systems that were obsolete by the time they were fielded, since the development cycle took so long.  People in our industry began to realize that many of these programs were doomed almost from the start by evolving scope, impossible schedules, and overly complex design.  And as our industry has matured, there have been many attempts to get it right.  From the business side, by trying new contract strategies.  From the engineering side, by formulating new development methodologies.  From the management side, by attempting new organization styles.  At best, it’s still an evolving science.  Two programs rarely fail for the same reason.  A maxim succinctly puts it: “Hardware is Easy, Software is Hard”.

A Software Systems Engineer

Maybe it was time to put all those hard lessons I’d learned into a career shift.  I accepted an offer as a Software Systems Engineer on a Foreign Military Sales program. The difficulty factor was exacerbated by another layer of complexity: a customer with a different culture, language, and world view.  And the ‘commute’ was halfway around the globe.  In spite of the difficulties, the work is accomplished.  A new system.  Facilities upgraded.  Gleaming new hardware, faster processors, better communication links.  Officers and enlisted men trained and prepared.  They wait for a war that will likely never come.  If it does, will the system perform to expectations?  I hope we never have to find out.

The Last Hurrah

A new program beckons, massive in scope and complexity, an Army modernization effort on a grand scale, so big that it’s called a System-of-Systems.  New hardware, new sensors, new communications infrastructure; a new way of conducting warfare. Our team is a small but critical cog in the overall machine.  We’re eager to apply best practices, to get it right. But a couple of years into the program, the same problems have surfaced and the initial optimism has faded.  The management team meets, strategizes, (following the latest trendy ‘Kaizen’ approach).  We evolve an idea that has worked before, but fit to our situation: we slice up the development schedule into short increments.  We break down the requirements into manageable chunks that can be separately managed and developed.  We call these chunks ‘Features’.  We create small teams of systems, software, and test engineers, and give each team ownership of a Feature.  Each team member has a vested interest in all aspects of the Feature.  It’s the same strategy that evolved in the Japanese car-manufacturing industry in the 1980’s, with a dollop of Agile.  By vesting interest, you get commitment to design the feature right, to test it more rigorously, and surprise!  It rolls out with fewer defects.  A modest success; our small contract is on time and on budget over five successive build cycles.  Our customer is pleased, our award fees are the highest.  Alas, the overall program has been bludgeoned by the club of irrelevance; a new battlefield of insurgents has emerged, operating on time-honored principles of asymmetric warfare, within a foreign cultural milieu, wreaking havoc on conventional military strategy.  It’s a battlefield that our original requirements were not formulated to address.  No amount of retrofit can rectify all the shortcomings.  The drain plug is pulled…

Cashing in the Chips

The day had finally come.  No more work available, a tempting retirement offer.  The idea of ‘leisure time’ after forty years of work.  Could it really be?  Wasn’t it just a few years ago I was the young gun in the group, ready to take it all on?  OK, today the world is full of sharp young entrepreneurial engineers.  There’s a new world of web-based applications, new platforms, languages, and ways of interacting.  But the old problems haven’t gone away, as anyone who’s neglected to keep their anti-virus software up-to-date will attest.  Software patches and updates roll out on a furious schedule.  I hear faint echoes from the trenches.  For anyone who has not read it, pick up a copy of Tracy Kidder’s Soul of A New Machine.  It’s a 30 year old tale from those trenches, but as relevant in some respects as the day it was published.  I suspect it will still be so in 30 years time.

Retired?? (Maybe part time Cool)

So that was a year ago.  Now I’m contemplating my future, ready to head off in a new direction.  There’s a lifetime of lessons to pass on to the next generation.  Technologically we have come a long way but there are new issues to address.  I’m not sure exactly where I'm going, but I'm ready to go!