Tech Development Styles for Cynics

A few days ago I mentioned Scott Berkun posted an interesting side-topic on Asshole-Driven Development. At the time, I said, you know your industry has some underlying, seething critique a-comin’ when cynicism is the standard frame-of-mind used to describe problems.

Well, I couldn’t have been more right. Scott’s post was Dugg, temporarily slowing down his whole operation. It seems he hit a nerve, and hundreds of folks came out of the woodwork (including myself) with variants on his theme. About 100 variations were offered up, between Scott’s comments (as of this posting), Digg, Reddit and a mention on O’Reilly.

Given my interest in cases where management goes awry, I was greatly entertained. So much so, that I did some categorization on the responses. I read through all the posts, tagged them with some keywords and concepts, then double-checked those encodings against major themes as they emerged. Effectively I did some electronic card sorting, though without the tape, note cards and holes push-pinned into my walls. Taking Scott’s initial “styles” as themes, here’s the strengths of his original development styles¹:

Variation Groupings

• Asshole Driven development (ADD) = 7 similar comments
• Cognitive Dissonance development (CDD, “two different beliefs for solutions”) = 2
• Cover Your Ass Engineering (CYAE) = 13
• Development By Denial (DBD, “pretend there’s no problems”) = 12
• Get Me Promoted Methodology (GMPM) = 7

Taking into account I have 98 on my list, that’s a pretty good informal correlation between Scott’s development styles and general sentiment.

For your consideration, here’s a few other trends.

Asshole-Driven Development

When it comes to assholes, it’s clear from comments they come in two flavors: those who are stupidly assholes, and those who are intentionally assholes. In fact, given the resonance of Scott’s blog post title, it’s surprising how few asshole-related styles came out in the comments. I expected more. Granted, asshole behavior is a common thread in all the categories. But Scott’s comments indicate that asshole tendencies are not strictly top-down. They work laterally, too.

Cover Your Ass Development

CYA was by far the most interesting archetype, in the sense that many people confessed participation in one scheme or another. Judging from groupings, CYA behavior includes:

• finger-pointing at departed colleagues, dumb customers, bad clients, ignorant bosses, difficult QA
• citing issues with scope, redundancy, technology choices
• hiding behind unknown technology, job titles, or an upcoming departure
• lots of throwing things over walls and job titles into other peoples’ laps

Development By Denial

DBD is also a very nuanced category. Most comments centered around delaying key metrics until after launch. Little things like design, usability, real functionality, clarity, clean-up, planning maintenance cycles, etc. Out of the group, two deserve special mention: “The Process Development”, as added by Chase, wherein ”…the process of the project becomes more important than the project itself.” I almost wished I worked within such a team, until I read his description. Ouch.

The second special-mention in denial-based development methodologies is by Caleb Jenkins, the “Marco Polo Process:”

[MPP is] where the customer stands in one spot and says “Marco”, and so the developers start blindly coding in that direction, only to get there and find that the customer has moved yet again, “Marco!”, so [the developers] start blindly coding again in another direction. Process continues until everyone gets tired and decides to finally get out of the pool. “Polo!”

Now that’s just funny. I imagine the Wii Mii Parade music playing in the background.

Get Me My Promotion!

To be honest, promotion- and accolade-related themes were focused on employees and managers selling each other out. However, a second theme arose in the comments: development driven (or not driven) by classic workplace villains like patent races, lawyers, good ol’ boys networks and general inertia as bosses wait out retirement on their initial cash cow, limping to the finish line. Given the youth of the tech industry, I was surprised to see those themes. They seem…quaint, in a maddening kind of way.

Cognitive Dissonance

Given more than 140 comments and 100+ additions, I’m surprised Scott got 4 out of 5 major themes² right. Cognitive Dissonance he missed, at least in popular agreement. Only one other person mentioned a scenario where a project was divided between two poles. In essence, troubles are big enough with just one. Enough said.

Other Categories

Using a loose grouping method based on my tagging, I found a few other themes in the comments. They exposed some interesting trends, so they’re worth sharing, too:

Feature-itis

I broke out a new category centered around feature-itis, also know as layering on more requests in the middle of development. A handful of comments condemned the same thing: somebody selecting a specific technology-base, regardless of whether it solves the problem at hand. Other comments included classics like adding in untrained resources late in the game and chasing every customer request without filtering them. I counted 10 comments centered around feature-itis, but a handful of others could apply, too, like scope-creep and “Not Knowing What You Want Until You See It (NKWYWUYSI)”, as volunteered by Minaki Serinde. It’s a well-known problem.

“This Here is a Run-Out-the-Clock Situation”

Another major, striking trend in comments was what I call “run out the clock”. This happens when a project is so bad, it is better to keep pushing it slowly along until all interested give up than deal with correcting direction. Like Sisyphus, I suppose. Some people suggested you could run out the clock by over-engineering or over-documenting things, or by taking feature-itis to an extreme. Others suggested that this process could also be fragmented across multiple releases, which might be even more terrifying.

Seagull Management

“The seagull manager flies in, makes a lot of noise, craps on everything then flies off again leaving a big mess behind” —the urban dictionary

There’s not much to say about seagull management, other then comments citing seagull management generated some great visuals, like whack-a-mole and a decapitated chicken. Enough said.

Fatalism

On the bitter side of things, a small collection of comments referred to development teams working on a project with a visible executioners axe hovering just overhead. Yuck. All three development style titles are wonderfully colorful, so I’m going to include them:

• Dead Man Walking Development (DMWD), by Bill
• You’ll Be Gone, I’ll Be Gone (YBG IBG), by Connor Murphy
• Irrelevant Development (And We Know It), by Lynn Cherny

Just Lousy Management

The largest theme of all was bad management techniques at play, with nearly 20 entries. Maybe I could have been more granular, but the centered around budget myopia, aiming only for “low-hanging fruit”, cheap hiring/staffing plans, selling the product before building it, absenteeism³ and—my favorite—the classic “too many chiefs, not enough indians” (which got 3 entries alone…it’s a cliché because it’s true). Out of the wide variety of descriptions of such problems, one deserves special mention for its amazing sagacity: “Can’t Polish a Turd (CPT)”, volunteered by John. I’d explain, but any explanation I could give really would just dumb it down.

Bad management did include one shocking development style, volunteered by Terry Bleizeffer. Terry wrote:

”…you’ve forgotten a biggie—Learned Helplessness Development—in which team members have been beaten down for so long that they assume that no matter what they do, they’ll suffer because of it. It’s the result of frequent and random negative reinforcement combined with infrequent and random positive reinforcement.”

A list like this is bound to bring out humorists, cynics and satirists alike. But sometimes an underlying distress rises to the surface, which is exactly why I think these kinds of lists are so valuable. Terry’s got a point, and shines a small light toward a dark corner of the tech industry. (You’ll no doubt find more commentary about the psychological problems of the tech industry here on Lost Cog in the near future.)

Egomania

The last major theme I found that is worth reporting is egomania-related development styles. They come in two types: a rockstar developer who carries the team in times of dire need, or the “rockstar” developer known as the teacher’s pet behind his or her back. They’re really so simple I don’t have much to add. Having briefly worked with just such a rockstar, I remember the look of dread in his eyes when we’d approach as a team. No amount of apologizing can cover for his lack of a social life.

Footnotes

¹ This is by no means a formal count. I fully admit I probably missed a few, and my groupings are based on my own readings, not some objective method. I also skipped a few I found hard to understand.

² Yeah, you could argue subsequent comments matched because to the “power of suggestion” or other psych-study biases, but, c’mon now. I’m not attempting scientific methodology here, and Scott’s a very smart man—an expert in the area of project management. He nailed them.

³ “All-But-Vacuum Management” was my own addition to the list, wherein management basically offers no guidance until they feel the need to sweep in and do something pointlessly drastic. Like seagull management, but with even less management.