Processes and Methodologies Won't Help You

Original from 3/4/2011: Gestão 2.0

After so much time talking about methodologies, processes, procedures, there’s one thing that should already be obvious but that most companies ignore: methodologies will never replace good professionals.

If I say this to anyone, everyone will say: “but that’s obvious.” And my urge is to retort: “then why the hell are you trying to implement this methodology?”

First of all, let’s go through some definitions:

• Methodology: a system of methods used in a particular area of study or activity.
• Processes: a series of actions or steps taken to reach a particular goal.
• Procedure: an established or official way of doing something.

Notice that in software development we always talk about processes or methodologies, never procedures. That’s because there’s no established or official way of making software. The problem is that most people confuse processes and methodologies with procedures and try to apply them as if they were the “official” way of making software. And they aren’t. Precisely because of that, disputes like Agile vs PMI, for example, don’t make sense. PMI calls its set of processes PMBOK, where BOK means Body of Knowledge precisely because it isn’t a procedure — it’s just a body of knowledge that may or may not be useful depending on your sector of activity. Agile is no different: a set of methodologies and techniques that may or may not be useful in your company. None of them, and none of the others, are procedures. Understand this first.

Once you understand that, comes the second mistake: people who don’t practice software development identify that the software being generated is of low quality. The indicators are obvious: customer complaints, internal complaints, perception of excessive delay in completing any software work, and so on. Seeing this, the first conclusion they reach is: “we’re missing procedures.” And the search for the missing link begins. They find various processes and methodologies and try to institutionalize them. For a short period it seems the result is what they expected, but it doesn’t take long to see that things haven’t changed all that much, and then they blame the methodologies for “not working.”

Software Development is an activity of “practice” — and watch out, “practicing” and “being practical” aren’t the same thing. So one more definition:

Practice: 1. the actual application or use of an idea, belief, or method as opposed to theories about its application or use. 2. repeated exercise in or performance of an activity or skill so as to acquire or maintain proficiency in it. (Read a more refined definition on Wikipedia.)

Repeat with me: if you don’t practice software, you don’t understand software. In the same way, it’s no use saying you were good at soccer 10 years ago, but you don’t practice anymore yet still want to believe you’re still good. No, if you haven’t practiced for 10 years, you’ve been bad for 10 years — there’s nothing to discuss. And in software, not practicing continuously, daily, deliberately, for 5 years is the same as a civil engineer saying he hasn’t practiced engineering in 50 years. 5 years in software age is an eternity.

And if you don’t practice software, you have nothing to say about it, by definition. So here’s the tip: processes and methodologies won’t help you, precisely because they aren’t procedures. If software had a procedure, it wouldn’t be a practice. Just mechanically follow the series of steps and at the end you’d have quality software. More than that, if it were a procedure, it would already be possible to have software that generates software on its own, with no human help. But that doesn’t exist, and won’t.

If a restaurant has bad food, processes won’t help it — changing the cook will. If your orchestra plays badly, it isn’t process that will help it — changing the musicians will. If your soccer team plays badly, it isn’t process that will help it — changing the players will. Replacing them is perhaps drastic; before that I’d say “practicing,” “training,” will certainly help. But here’s the thing: if your soccer player believes he only needs to play after he punches in his time card, and can stop when he punches out, he isn’t a good player. So forcing them to train won’t help, and consequently, processes and methodologies definitely won’t help you.

With a good programmer it’s the same. You don’t need to force him to put his code into a versioned repository: he himself will miss it and do something about it. You don’t need to force him to test his code, he himself will miss it and do something about it. You don’t need to force him to refactor his code, he himself will feel that it’s bad and do something about it. A good practitioner doesn’t need others to tell them what to do: they know what constitutes good work and will perform accordingly, or they will look for what they’re missing and train until they become proficient at it.

A good practitioner takes it as reality that they have to be better today than they were yesterday and continue at that pace every day. A procedure professional knows that today’s work is the same as yesterday’s. That’s the difference: if your company manufactures screws, it follows procedures. Today there are people assembling those screws, following procedures; tomorrow you’ll probably replace them with machines that will do the same job better and faster. That’s the destiny of every procedure professional.

If your company is in gastronomy, music, sports, literature, art, software, etc., you want practitioners. If you don’t have them, remember: processes and methodologies aren’t procedures. Processes and methodologies can’t be installed as procedures. Processes and methodologies will never transform people with a procedure mindset into practitioners. And without practitioners, your result will always be bad.

We’ve been developing software for over 70 years. If the solution were that simple, don’t you think everyone would have done it that way decades ago with continuously, for decades, excellent results? Don’t be naïve thinking you’ve found the “missing link”: it doesn’t exist.

The only thing we can do, always, is to try to be better tomorrow than today. But that isn’t done with meetings, committees, procedures, magic recipes, gurus, or talks. It’s done with practice. Want to be better at software? Practice software. Now, do you have a good team, good professionals who really care about practice? Now yes, refining the processes and applying good techniques and tactics will improve things even more. But the order is this: good professionals first, then good methodologies. Repeating: good methodologies don’t create good professionals, but good professionals will certainly know how to take advantage of good methodologies.