When listening to the radio last week, I heard somebody use the phrase “constructive pessimist.” This label captures the essence of what I think makes a great software developer. It is the kind of developer I want to be and especially have on my team.

As I thought this over, a model of sorts formed in my mind that describes four different types of engineers, each with a unique reaction to the challenges of software development. I’m calling it…

The Dutch Boy Model of Engineer Archetypes

The notion of a “constructive pessimist” implies a cartesian coordinate diagram of worker types, where each quadrant represents a unique reaction to the challenges of software development. These four engineering personality types, shown in the diagram below, typically encompass everybody on a software team.

The types can be summarized by looking at how each would handle the old fable of the dutch boy who encountered a leaky dike. Upon seeing the leak:

• The destructive pessimist knocks you down and runs away, “We’re all going to die!”
• The destructive optimist blocks your access to the dike, “Don’t worry about it, the leak will fix itself.”
• The constructive optimist sticks a piece of gum in the hole, “I fixed it!”
• The constructive pessimist sticks his finger in the hole and yells, “This won’t hold for long, go get help.”

Working with (or for) the Archetypes

These types of people are particularly obvious in software projects, but you can recognize them pretty much anywhere. Here is a more detailed description of the how each person functions in the workplace:

When faced with a serious challenge…

The destructive pessimist often defaults to, “We can’t make it work so I’m not going to bother trying.” His actions that follow usually amount to sabotage of some sort. The sabotage probably isn’t technical; it may be social, political, financial, or even just a hit on morale, but the effect is the same. This guy is poison. Fire him or get him off your project. His approach may be a character flaw or just burnout on your particular project. Either way he needs to go and take any schadenfreude with him.

The destructive optimist says, “We can make it work, but I won’t need to do any hard-core planning, designing, thinking, or testing. We’ll be positive and start coding, and we’ll do just fine.” Like the destructive pessimist, he is also an insidious influence on a team, but the effects are much more subtle. This guy is harder to get rid of, because everybody probably likes him. He may be very smart and a “good coder,” but he is an Eloi with a keyboard, unaware of the tough work required below the surface of challenging software. If you’ve heard the phrase, “Well, it worked on my machine,” it probably came from a destructive optimist. This guy will probably also refuse to document his design, comment his code, or do automated testing, because he thinks everything he does will always work just fine.

The destructive tendencies really come out if he is a manager or team lead: He’ll overrule requests for extra testing resources, he won’t manage scope creep in requirements, and he won’t recognize (or react to) the warning signs your project is headed for failure. This is also the guy who will throw extra people and overtime at the last minute on your failing project, optimistically thinking that nine women can make a baby in one month.

The constructive optimist is a fine person to have on your team, because a positive attitude and substantive work toward the goal are essential. “It will work, and I know what to do to get there.” This attitude is great, as long as they really have done the work before and know that it works from experience or solid research. The danger comes in a tendency toward “sunny day” solutions that expect everything to function normally. They don’t tend to plan for failure.

A team comprised solely of these guys will happily build a Web 2.0 website, play ping-pong, and attract angel investors left and right. The site will work great until the public notices and brings it to its knees. Not knowing the folks at Twitter, I can’t say whether this applies to their early days. I’ll venture to say that 80% of 3rd-party Facebook Apps have the hallmarks of a constructive optimist, however.

The constructive pessimist says, “It won’t work unless we make sure to do it right.” He will instinctively find weak spots, conceptual holes, and problematic requirements, then work hard to find solutions. Solid experience and the desire to find solutions in the hands of a constructive pessimist are pure gold for your project. If this guy is given either significant influence or leadership on your team - and backing by management - your chances for success cannot be higher. I should say with great emphasis that this person doesn’t have to be negative or irritable … they can be up-beat and still communicate the need to plan for rainy-day scenarios.

You expect your IT guy to be a constructive pessimist, after all. Redundant systems, fail-over support, and off-site backups are all constructive ways to plan for the worst. If your software development team thinks along the same lines, your software should be better tested, handle network irregularities, recover from errors, and be less vulnerable to malicious users.

Shaping The Team

You can’t always pick your team from scratch, so the chances of getting a a dream-team of constructive pessimists is unlikely. With a little work, I believe you can help any engineers become a little more constructive pessimist, however. You don’t have to change their personality, but you can encourage them to think and work more effectively. As the saying goes: “Hope for the best, but plan for the worst.”

I’d like to follow up this article with a second part that discusses ideas of how to do this: How do we get people in the other three quadrants to move closer to constructive pessimism?

If you have ideas or anecdotes along these lines, please leave a comment and share your experience. If you think constructive pessimism is a crock, let me know. Or if you just have some great stories of these four types of people at work, I’d love to hear about them.