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.
Of course, what constitutes as friction frequently depends on your point of view. Meetings that might look like friction to a developer might be a valuable way to manage the strategic picture to someone else. To a product manager, refactoring might look like friction that slows down the release of new features. A developer sees the same activity as short-term necessary friction to prevent much larger friction down the road. The key, as usual, is to communicate intent and expected outcomes. When the goal of an activity is clear to everyone involved, the kind of friction that everyone agrees on can truly be reduced or eliminated.