The Wetware Crisis: TEPES

[Copyright 2008 by Bruce F. Webster. All rights reserved. Adapted from Surviving Complexity (forthcoming).] [Some edits and expansions made in 2018]

In my forthcoming book, Surviving Complexity, the very first section is called “The Wetware Crisis”. This is a greatly expanded look at a problem that I first discussed in print twelve years ago in the late, great BYTE Magazine, namely that one core problem today in information technology (IT) is that there just aren’t enough good IT engineers and that there never will be. The article itself focused on just one aspect: inherent talent. My argument, supported by various studies, is that certain people have inherent talents that help them in IT, just as others are gifted in math, music, language, and so on. My follow-up observation is that the percentage of really talented IT engineers in a given human population is (a) small and (b) fixed. (It’s hard to argue for natural selection causing that percentage to increase when we’re talking about geeks breeding.)

It’s telling that I received over 100 letters and e-mails in response to that one article (and remember that this was in 1996, when very few people had e-mail). Almost all of those responses said, “Yes! Thank you for stating what no one wants to acknowledge!”

I first became aware of this problem as an undergraduate student at BYU in the mid 1970s. One of my professors, who worked in industry but was taking a year off to teach, stated in class one day: “If you knew which ones to pick out, you could shoot half of all the people working in data processing [the generic term for IT back then], and not only would no deadlines be missed, many would be moved up.” When I graduated a few years later and started work in industry myself, I got a sense of what he was talking about as I observed a tremendous variation in the productivity of the people around me.

The key insight came several years later, when I myself went back to BYU to spend a few years (1985-87) teaching in the Computer Science department. I was talking one day with Dr. Gordon Stokes, who had been my undergrad faculty adviser. In my absence, the enrollment in the CS Department had exploded — from about 120 students when I was there to over 1,000 students — and you now had to complete prerequisites, apply, and be accepted by the CS Department in order to major in Computer Science. His observation: despite the nearly 10-fold growth in students pursuing a CS degree, the number of really talented students was about the same as it had been a decade earlier. Not the percentage — the absolute number. He felt that the students with natural talents and inclinations had been enrolling in CS all along, while the tremendous growth in the department was due to students who saw Computer Science as the new equivalent of Law or Medicine.

[Note: this growth in CS enrollment was not limited to BYU. From my research, it appears that CS enrollment hit a major — and possibly an all-time — peak all across the United States in the mid- to late-80s and then started to decline. If you read the articles that appear on a regular basis about declining enrollment in Computer Science, you’ll find that many of them pick as their starting point for graphs the year 1985 or thereabouts.]

As I went back out into industry, I found yet more evidence for what Gordon had to say. This was especially true in 1990, when I started to build from scratch a software team for a startup company (Pages Software Inc.). It took me nearly 18 months to hire 8 to 10 excellent software engineers. That process led me to state a rule of thumb (which, yes, I have submitted to RulesOfThumb.org): you have to read 10 resumes to find one candidate worth calling; you have to call 10 candidates to find one worth bringing in for an interview; and you have to bring 10 candidates in for interviews to find one worth hiring.

Now, over fifteen years after that experience, I’ve summed up the problem with a single acronym — TEPES — and, yes, it’s enough to impale (or drain the blood out of) any IT organization.

TEPES stands for Talent, Experience, Professionalism, Education, and Skill. These are the five aspects that separate an outstanding software engineer from a merely good one, much less a mediocre or wretched one — and trust me, there are plenty of mediocre and wretched IT engineers out there. One could argue that these same aspects are true for any profession, and I’ll let others make that argument. But I see two major problems or differentiators with IT. First, the demand is so high (except for the occasional slump) that firms will hire just about anyone who can spell “computer”. Second, an IT engineer (or a collection thereof) can have a disproportionate impact on the operations and profitability of a given organization (or country) and can even have an impact of public health and safety. So let’s look at TEPES a bit.

TALENT. I’m not talking about a single talent or a simple has it/doesn’t have it assessment of that talent. Instead, there’s a small collection of IT-related talents, and each is on a continuum — say, 0 to 10 or, if you’re a old-time D&D fan, 3 to 18, — except I’m not sure the talent follows either a uniform or a standard normal distribution.

The talents tend to correlate with the standard software development lifecycle — analysis, architecture/design, implementation, and quality assurance — though that appearance may be an artifact of the lifecycle itself. There are individuals who have tremendous analysis “look ahead”, absorbing information and seeing solutions paths and complications that would escape the rest of us (until too late). There are individuals who create elegant and robust architectures and designs that meet all the conflicting criteria to which a given IT system is subjected and then unfold naturally into unforeseen extensions. There are individuals who disappear into their office for a few days and come back with thousands of lines of clean, defect-free source code, which seems to appear almost as fast as they can type. And there are individuals who can take a defect reported in a complex IT system with astronomical numbers of possible states and yet quickly hone in on the source of that defect.

And then there’s Don Knuth.

The point is, talent makes a tremendous difference in both productivity and quality, and yet talent is by and large ignored, poorly screened for, or unrewarded in many (if not most) IT organizations. And it’s in limited supply, compared to the demand. But, as I noted in my original BYTE article, talent is not enough (though it can overcome an awful lot). So let’s move on to the next item.

EXPERIENCE. Years ago, while we were both working for OSG Incorporated, my colleague Bruce Henderson did a screening interview on a candidate for a software architect slot we were trying to fill. The young man — and he was only a few years out of college — was obviously bright and knowledgeable, and he presented himself well. But Henderson passed on him with this comment: “If he were a fish, and I had caught him fishing in a lake, I would throw him back to let him grow a bit more.”

There are critical lessons in software engineering that only come through experience, particularly painful experience. Possibly the single most valuable year in my professional life was the full year that Pages by Pages (our NeXTstep-based word processor) was late in shipping. As I later stated in my introduction to Pitfalls of Object-Oriented Development (a book that sprang directly from that experience):

Somewhere into our third year of the Pages project—developing a full-blown, commercial object-oriented document processor—I was sitting in my office, rereading The Mythical Man-Month by Frederick P. Brooks. Dave Krich, our director of quality, wandered by, looked in, and quipped, “Isn’t it a little late for that?”

It was indeed. We were approaching our originally announced release date, and we knew we weren’t going to make it. But Dave’s comment and Brooks’ book set me to thinking about all that I wished I had known when I blithely started the Pages development effort some years earlier. I started making a list—mentally at first, and then on paper—of the pits we had fallen into along the way. I added those we had skirted and those we had avoided outright.

The experience of having to go before the investors every month for that long year and explain to them why we hadn’t shipped yet and when we now thought we might burned into me lessons that I would not have learned any other way. It also burned out of me the native (and sometimes naive) optimism of software engineers who haven’t been through such a setback. So, yes, experience matters.

PROFESSIONALISM. IT engineers are famous for being a bit, ah, playful at work and even a touch adolescent, as a visit to ThinkGeek will demonstrate (hey, it’s one of my favorite online stores — and, yes, I have an animatronic chimpanzee head in my office). But that’s a natural stress-release in a professional that routinely asks its workers to put in vast amounts of overtime on a flat salary basis, sometimes for months on end (the “heroic” model of software development). And given the challenges in finding, hiring, and retaining outstanding IT engineers, a few perks and a bit of goofiness are a small price to pay.

But sometimes you get IT engineers who slide into full-blown primadonna-hood. They become arrogant, thinking they’re right and that everyone else is not only wrong but an idiot to boot. They disrupt team efforts, make unreasonable demands (not requests), and can hold entire projects hostage to their opinions and whims. They can quickly conflate their personal lives and struggles with their professional work. Even if such engineers are very talented — and some are, though most not nearly as much as they think — they are, in the end, not worth the troubles of keeping them around.

EDUCATION. The role of education in IT and software engineering remains somewhat controversial, mostly due to criticisms that CS departments, as a rule, don’t prepare their students for real-world software engineering. (On the other hand, there’s another argument that too many CS programs are not really teaching computer science — and that’s a scarier issue, as far as I’m concerned.) It is also true that one of the most brilliant software engineers/architects that I ever worked with had only a GED and few, if any, college classes. But my observation is that a solid foundation in computer science and ongoing reading and research are important for excellence in IT engineering and will give you an edge over those who lack it.

Beyond that, many talented IT engineers (and even more less-talented ones) waste their time re-inventing the wheel, both in a technical sense and in a process sense. One of my all-time favorite quotes, from George Santayana, applies especially well in this sense: “Progress, far from consisting in change, depends upon retentiveness…Those who will not remember the past are condemned to repeat it.”

SKILLS. Specific technology skills are perhaps the least important aspect, yet they are the ones most often focused on by organizations that are recruiting IT engineers. If an IT engineer is talented, educated, professional, and has experience, s/he will be able to come up to speed on the technologies involved — given a bit of time and space. That can be a very worthwhile investment and can gain the loyalty of the employee, since the opportunity to learn something new (while getting paid for it, no less) is one of the most sought-after perks among IT engineers.

However, if you have a full-blown project going on with a tight deadline, then you probably do want someone with the relevant skills in place, rather than someone who has to go through the learning curve for that technology. It goes back to the “reinventing the wheel”/”making all the first-time errors” problem that come from lack of education. All other aspects being roughly equal, actual skills prevail over a lack of skills.

So there you have it: TEPES — talent, experience, professionalism, education, and skills. I believe all these factors are important, but I also believe the acronym ranks them in importance (first talent, then experience, etc.). Comments?

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.