Process and Personality

Let's talk about me for a minute. What am I like? I'm uncomfortable with conflict. When caught in the middle of an argument, I try to find ways each side might be partially right. My father built houses. From him, I absorbed a frustration with designers who think of themselves as being above the grimy details of construction. I'm comfortable managing tasks by dealing with the most pressing one next - what Brian Foote calls "kicking the nearest wolf from the door." And I keep abandoning career plans to jump at opportunities - profitably, so far.

I've made a career as a software consultant. Oddly enough, my methodological prescriptions and approach match my personality. Because I've always liked to plan as late as is safe and maintain flexibility as long as I can, I like agile methods. To avoid fruitless conflict within the team, I steer testing groups toward thinking of themselves as support staff for project managers, not as heroes engaged in a deathless struggle to protect the helpless users. Because I believe that you can't escape the grimy details of construction, I tell clients that all methodologies must be changed to suit the particulars of a project and its people.

Of course, I can justify my approaches, showing how they're grounded in careful reasoning and historical experience. But let's be frank: my approaches are not just compatible with my personality - they're derived from my personality. And so are everyone else's, even though they also justify their approaches with history and reason.

Every article on methodology implicitly begins the way this one did: "Let's talk about me." Methodologies and techniques are created to help their developers get ever better at what they do, while allowing them to be who they are. So those people who like things laid out as a whole for dispassionate review create and refine inspection techniques to make them better at such review. Other people feel unsettled without interaction and exploration, so they create and refine test-driven design and pair programming to help them do that better.

In the long run, we may discover that one or another personality type is simply better suited to software development. For example, we might all come to agree that the exploratory software person is like the conciliatory lawyer, the disorganized accountant, and the indecisive physician - they're all wrong for their professions. That would be okay.

Many are ready to decide that today. They have decided that the right personality for software is the meticulous one they associate with conventional engineering. They are even willing to encode that decision in certification programs or lists of mandated "best practices." That is not okay. Making software development inhospitable for other personalities will mean we'll never learn what they could do, left unhampered. I think we should be more modest and more willing to defer judgment. (Of course, there's my personality speaking again.)

I suggest we embrace diversity. Let's stop talking about best practices and start talking about what practices work best for us, right here, in a particular team, with that team's personality. Let's expect different teams to do the same job entirely differently. Let's not judge them against a single standard of practice. Rather, let's judge them by past results, by how well they can explain why they do the things they do, by the breadth of alternatives they've tried and discarded, and by their self-awareness.

This essay was originally an editorial in STQE.