The Reverend Bill Blunden is a rogue engineer and a SubGenius preacher who is currently at large in the Oakland area. (We're not precisely sure what "denomination" the "Reverend: preaches under.) He has an undergraduate degree in physics from Cornell and a graduate degree in operations research from Case Western Reserve University.
Reverend Blunden has written a number of books, including Software Exorcism A Handbook for Debugging and Optimizing Legacy Code, Cube Farm, and another book (yet to be named) on offshore outsourcing. At the time of this interview Cube Farm is in production at Apress in Berkeley. When we read an early version of the book our jaw dropped over some of book's revelations and we felt our readers, particularly those of you with a development background, would enjoy hearing some tidbits from the book and about what may be the most dysfunctional software company we have ever heard of.
SMS: Ok, what is your background in software? What was your college major? What type of products have you worked on, why did you write Software Exorcism, why are you writing Cube Farm? Oh, and where did you come up the title Cube Farm?
Bill: I entered into the software game strictly out of necessity. For all of the hoopla that I hear about the shortage of mathematicians and scientists in the media, no one wanted to hire a physicist after I graduated from Cornell (especially in a service-based economy like my home town of Cleveland). Whenever you hear someone in the media claim that they can't find the engineering talent that they need, you can bet that they're probably going to bring up the topic of visa workers or offshore outsourcing. It's just an excuse that corporations use when they don't want to hire American workers.
Cube Farm is an allegory. The book describes, in gory detail, my three years working as an engineer in the Midwest and is intended as a warning to undergraduate students everywhere. Having the unbridled enthusiasm of a greenhorn, I stepped on damn near every landmine that exists in the business world. Many times, I fell right into the traps that unscrupulous management types set for guys like me. I was cannon fodder. If I can save one person from being victimized like I was, I will have succeeded.
In Software Exorcism, I offer a set of tools that can be utilized to debug and enhance old legacy code. Cube Farm is the story behind Software Exorcism. It's the human backdrop behind all the technical strategies in my earlier book.
The term "cube farm" is office slang, and describes the working conditions of the typical white-collar schmuck: row after row of identical, mass-produced cubes. They offer little or no privacy and zero protection against that one guy who turns on the air conditioning in December. By the way, did you know that companies often install fake thermostats in their office buildings? It gives the peasant-folk the feeling of control without actually giving them any.
SMS: Considering we're located in snowy New England, we feel chilly already. OK, Cube Farm begins with your leaving college and entering the workplace. What happened?
Bill: Well, I quickly found that my college career had not prepared me for the realities of the workplace. In college, you learn that things are binary, truthful, that you work in a meritocracy. If you follow and apply the processes you've been taught, things go smoothly. Of course, it doesn't work this way in the real world.
SMS: Wait, let us guess! When you graduated from school, you discovered that the world was a swamp of intrigue, double dealing, and political backstabbing. Who would have guessed!
Bill: Laugh if you must at my naiveté, but I confess that I thought the working environment would be more straightforward and logical than what I found.
SMS: Continue with the story of your odyssey.
Bill: Well, after I graduated with an MS degree in 1997, I received a job offer from a major software firm in Minneapolis and accepted it. They wanted me to do R&D work that would involve significant amounts of Java. The only other real alternative I had was to maintain COBOL code for an auto insurer in Cleveland.
From 1997 to 2000, I lived and worked in Minneapolis. I witnessed corporate infighting, cube farm intrigue, and Y2K preparation. It was quite an education, one that I earned the hard way.
(Editor's Note: We have decided, for purely crass and commercial reasons, to not reveal the actual name of the large software company Bill writes about in his tome. The name will be revealed upon the release of Cube Farm in the summer of 2004 and it is our earnest hope that speculation and gossip will help increase the book's sales.)
SMS: What kind of software did the company develop and publish?
Bill: Business software, primarily ERP stuff aimed at many verticals. The business application code was tied together by a thick, spaghetti-like layer of middleware (developed in-house).
SMS: What were your first days on the job like?
Bill: Very interesting, but not very busy. I later discovered I'd been hired as part of what was, for this company, a normal practice-empire building. It was fairly common practice at this firm to increase head count by hiring people who were quite deliberately expendable. The larger your organization, the more power your group or division accumulated in the company. Productivity, developing code, getting products to market were all secondary to the goal of increasing your corporate clout.
As a result, I didn't see the hiring manager for six months after my arrival at the job.
SMS: You're joking.
Bill: No, I'm not. At this company there were large groups of what I called "ronin," leaderless "samurai." These consisted of people assigned to projects that had been failed, canceled due to politics, technically deficient, etc. People would spend their time taking long lunches, working on personal development, goofing off, trying to develop their own projects. That's what I did once it dawned on me that no one was going to ask me to do something. Then I was finally assigned to project, which was cancelled after a few weeks. Then I was assigned to another project, which also promptly fizzled.
SMS: Then what did you do?
Bill: Well, I decided it would be useful to attend the company's internal university, a series of courses ostensibly designed to teach you about the internals of the company's proprietary code and tools.
SMS: That would seem to be a productive way to spend your time.
Bill: That's what I thought, but things aren't always what they seem. For a "university" the courses given were rather odd in that there weren't any training materials or documentation. They gave us empty manuals that we were supposed to fill in during class. Perhaps they thought it would keep us on our toes rather than frustrate us into a mutiny. By the way, this didn't simply apply to the course, but to the source code itself. Sometime in the past someone had written a program that stepped through the company's key code programs and removed all the comments and documentation from millions of lines of code.
SMS: You…are…kidding. This sounds like something out of a Dilbert cartoon.
Bill: Truth can be stranger than fiction! Finding actual information about how our product's worked written down somewhere was like finding a diamond in a pile of mud. One consequence of this act was that to actually learn something at the company required you enter into a sort of master/acolyte relationship with people further up the corporate food chain. You'd show up, pay homage, swear allegiance to your mentor and in return they'd teach you something, explain some of the code, show you how things worked. Over time, if you worked hard enough and learned enough, you could hope to become a 'truck number."
SMS: A truck number?
Bill: Yes. A truck number was someone who, if they were hit by truck, would bring the company down. They were the company's architects, chief programmers, keepers of the code; the lord high executioners of ERP middleware. Over time, some of these people had become more and more powerful as attrition had whittled down the number of people who knew how the company's products worked to an ever smaller group.
SMS: What was the role of upper management in creating this corporate culture?
Bill: They were directly responsible. This software company was, at the time of my employment, family owned and there was always a healthy amount of infighting taking place between the various brothers and cousins and whatever who "owned" different divisions of the place. For instance, one family member decided to create his own "fiefdom" within the company and called it "The Advanced Technology Group." This was particularly slanderous, given that the "Technology Group" already existed.
SMS: Oh, god. We know how THIS one works out! Of course, everyone wants to either work for "The Advanced Technology" group or wants to call their group "The More Advanced Technology Group" or "The Penultimate Technology Group" or whatever.
Bill: Precisely. And along with this mindset came the other ills common to highly dysfunctional organizations.
SMS: Can you give us some examples?
Bill: Well, there were plenty of manager's who'd learned never to write anything down. That's a sure way to avoid responsibility for failure. I worked for one manager who inherited, much against his will, a CASE tool for which, guess what, no documentation existed. I in turn inherited development responsibility for the product, which was an exciting prospect. When I met with my "manager" to discuss the development and promotion of the product he was always careful to never write anything down that pertained to project schedules and specifications. He was also careful to not answer E-mails that dealt with details of the product.
This carried over to the company as a whole. Everyone had learned to never leave a paper trail. As a result, projects were always being started and then abandoned with no one ever quite sure of who was responsible for what, or when, or what happened.
SMS: Let's talk about your interactions with the other groups in the company? Did you ever work or communicate with the firm's product managers? How did they function in respect to development?
Bill: The Technology Group was in its own little hothouse environment. The senior engineers seemed to do whatever interested them, as opposed to adding value. It was very experimental: lots of R&D, lots of research, and very little development. The managers, not knowing any better themselves, encouraged this because doing something was better than sitting on your hands. They needed to present the illusion of progress to their superiors and our pseudo-projects were good enough. This gave rise to all sorts of exotic software applications, like a fuzzy logic engine or a Java-to-COBOL compiler.
We had little or no contact with the rest of the company. As it was, we had our own building, isolated from the other divisions. Product managers? What in the heck are they? I was so far down the hierarchy Christmas tree that I was lucky if they remembered to call me to meetings. I was a warm body, a head count, nothing more, a nameless, faceless entry in an accounting database.
SMS: Same question as above, but in regards to sales.
Bill: Upper management hired these bombshell blondes to do sales. Beautiful Viking women, armed with shields and spears. Some of my fellow engineers disparagingly referred to them as "demo dollies," but they always made me hear Wagner in the back of my mind: The Flight of the Valkyries.
Other than the occasional afternoon daydream, that was about it in terms of my contact with sales people.
SMS: What led to your decision to leave this company?
Bill: The Feds finally caught up with me on a case that I picked up in the late 1980s. Damn that statute of limitations.
Really, though, I worked with many people who had been with the company for over a decade. I took a good hard look at what it did to them. Did I want to end up like that? Was a life sentence to a cube farm purgatory worth the security? In the end, I weighed risk against suffering and I left in 2000 having reached the conclusion it was not.
As it turns out, when the company went public, it booted most of the old-timers. So the old lifetime employment deal was a sham. As soon as the founders got enough money to retire (read IPO), the long knives came out and the blood flowed. This was all during the post-9/11 downturn, which I'm sure added insult to injury.
SMS: OK, let's assume another fresh-faced, idealistic geek has graduated from college and finds themselves in the same predicament. What is your advice to them?
Bill: Take some time to decide what you really want to do with your life and then go do it. There's something to be said for the personal assessment that career counselors perform. The majority of people in life make decisions based on desperation, or they make decisions without recognizing how their options will be constrained over the long term. You can only cruise along on autopilot for so long before you become hopelessly lost. If all else fails, live dangerously and surf the luck plane.
SMS: When you were in college, did you ever receive any instruction on the real world as it pertains to business? Are there any courses or information you'd recommend undergraduates be taught?
BILL: Warren Buffet, the investment deity, once said that there's a fool in every market. As far as higher education goes, the undergraduate student is the fool in the market. The universities make out fine, and so do the banks that provide the educational loans. For example, students at Princeton will pay roughly $39,000 a year (see the Princeton web site) to learn things that nobody really gives a damn about (read, will not help you get a job).
Have you ever wondered why they pay professors so poorly? The reason why professors wear those ratty tweed jackets is that no one cares about abstract algebra, or philosophy, or art history. A college education may provide you with a collection of quaint facts that will help you in a game of trivial pursuit, but that's about it. If you want marketable skills without paying out your life savings, go take accounting and business at a community college.
Let me put it to you this way, Bill Gates was a Harvard drop out. He used to play a game to see how little he could study and still get an "A." This should give you a hint as to how important academia is in the big picture. If you get anything of value out of your undergraduate years, it will be the people you met and the life that you lived (and the hangovers you suffered through). The class work is utter nonsense. Personally, I think they should do away with it and make everyone work in a salt mine. At least it would build character.
I know this because I swallowed the Kool-Aid. I studied at Cornell with the zeal of a true believer. Every day, for 10-14 hours I hit the books like a madman. For all my toil, I was rewarded with unemployment and the kind of post-traumatic stress that can only lead to disillusionment. Looking back, I probably would have had more fun sticking up liquor stores and hanging around street corners. I'm not joking. Pelican Bay has got nothing on Cornell.
SMS: Let's talk about Software Exorcism a bit. The tagline says it's a Handbook for Debugging and Optimizing Legacy Code. Why did you write this book? And in an age of exciting new wonder languages like Java, C#, PHP, what's the relevance?
Bill: Software Exorcism, like Cube Farm, is a cautionary tale. In the end, software engineering is not about technical challenges. It's about navigating the political maze. People in the hard sciences, in particular, are less apt to be prepared to deal with this truth. If you don't believe me, go walk around a business school sometime. The B-school students will not look, or behave, anything like the geeks in the computer science department.
While I lived and worked in Minnesota, the company that I worked for had a middleware base that consisted of millions of lines of K&R C (some portions of which had been around since the late 1970s). The business logic, which utilized the middleware for general application services, was written in COBOL. The marketing people could spout off as many buzzwords as they wanted, in an effort to keep from looking outdated, but 99% of the code base was legacy. Rewriting was not an option, there was too much code; code whose internal operation was not well understood. Think Dead Sea scrolls.
In this type of environment, making progress was a dubious proposition. Management had no idea how anything worked and this made it difficult for them to judge the viability of their campaigns. As a result, they based their decisions on consensus and sex appeal. If a project used cutting edge technology and impressed the executives, then they went ahead with it, regardless of whether it was feasible or not. It was style over substance, all the way.
After three years of failing, I realized that failure (more often than not) was a product of behavioral dysfunction. Management attached itself to doomed projects for strictly political reasons. In light of this, the appearance of success was more important to them then actual success. Management's ulterior motive was to look good in the eyes of their boss, the chief executive (that's the thing about authority, everyone has a boss no matter how high on the totem pole they are). It didn't matter if you, as an engineer, delivered an operational solution. Mid-way through, the department would re-organize and your project would get lost in the shuffle. They'd find some sexy new technology to promote and you'd get drafted into the next lost cause.
Now, with regard to C#, .NET, and the like …
When I wrote Software Exorcism, I made a concerted effort to remain platform agnostic. In the book, I present a universal set of tactics that can be implemented regardless of the development environment or operating system being used. Sure, I wrote the code samples in C and C++, but in my mind these are least common denominator languages. C and C++ will be around for a long time. I don't think I can say the same for some flash-in-the-pan, proprietary language that happens to be in fashion.
SMS: OK, last question. You refer yourself as "Reverend Bob" in Exorcism and include the sign 0(e^x). Splain.
Bill: I'm an ordained minister in the Church of the SubGenius (praise Bob!). I thought that if I was going to write a book on exorcism, then I'd better be some sort of preacher man. I reckon. The O(e^x) is computer science shorthand for "on the order of the exponential function." It's intended to be a religious pun. You know, the Order of the Golden Dawn, the Order of the Rosy Cross, the Order of the Exponent, etc.
SMS: Bill, best of luck and we'd like to have you back when Cube Farm is released to discuss aspects of the book further.
Bill: Praise Bob!
