You've heard this mantra before, right? Don't bog programmers down in process, just let them get stuff done. Back when I lived in the corporate IT world, we would joke that any problem could be solved with more process. Indeed, at the time it seemed that was management's solution to everything.
But what does this statement even mean? It's started to grate on me because it doesn't communicate its intent. "Process" is too ambiguous. I have a "process" for tying my shoes, but it doesn't bother me one bit. When I lay my head down on my pillow and fall asleep at night, that's a process as well. So what's the real issue?
Programmers don't really hate process, programmers hate friction. Friction is anything that gets in our way, anything that slows us down. Heavyweight tools and processes are friction. Distractions are friction. Most meetings are friction. The list goes on and on.
Not all processes have friction, though. While I'm not in love with Pivotal Tracker, one thing it does well is stay out of my way. Github issues and pull requests do even better. Automated deployment scripts (that run fast) take the friction out of server interaction. We can't avoid process altogether, but we can choose tools and processes that minimize friction.
Why am I making so much noise over the difference between process and friction? Because "process" is devisive. It's easy to get caught up into thinking that developers hate processes while clients and project managers mandate them. It's "us versus them" thinking, and it's flawed because we all need some process.
Turn it around and talk about friction, though, and suddenly we're all on the same page. Everyone hates friction. No one wants to be slowed down. Just changing the phrasing of this little mantra can change perspective on your relationships within your company or project.
Keep the process. Kill the friction.
@mdoel Excellent points. Meetings are something I want to write about in a future article. Your comment gives me a good perspective to keep in mind.
@surfacedamage I wonder if the bigger difference is not tolerance for friction, but tolerance for risk. I don't think anyone would permit truly unnecessary friction, but as @mdoel points out, we all see what is necessary quite differently. A lot of what developers consider unnecessary friction is seen as necessary from other stakeholders for the sake of mitigating risk. It's too easy (for me, at least) to blow off this concern instead of talking openly about risk, friction, and the tradeoffs between the two.