Principles over process

hsoi blog, talk 0 Comments

As a graybeard in the world of software development, I’ve seen trends come and go, rise and fall, be declared the panacea that will save us all then naturally fail to do so because the next panacea has come along. Lather, rinse, repeat.

And so, today’s hot practices like agile, scrum, TDD, are buzzworded about, and worshiped like a god until the next god comes along.

This isn’t to say those practices don’t have value and merit, because they did come from somewhere — typically grown out of seeing problems, failures, and flaws in whatever was hot at the time of their inception. So in general, it is a growth, an evolution, and A Good Thing™. But they are just a new thing, until the next new thing comes along. This is why today we use git over svn, but git has its own new problems that will eventually be solved by some new VCS.

One that really gets me is “agile”. The main reason? Because once you start preaching agile process, you’ve failed at agile. See, agile isn’t about burndowns and velocities and charts and graphs and stand-ups and other things. Oh sure, I do think the concept of “stand-up” is good because it attempts to ensure relevant communication between relevant parties with an emphasis on a high signal-to-noise ratio and not wasting everyone’s time. But on the same token, is it right for everyone, every team, and every project? No, and it shouldn’t be blindly applied because it’s the new hotness. No, it’s just a tool and you should continue to choose and use the right tools for the job. A two-man team should be communicating regularly and doesn’t really need a formal “stand-up” every morning.

See, agile is, in many respects, anti-process. Rather, look at the first line from the Agile Manifesto:

Individuals and interactions over processes and tools

This isn’t to say processes and tools aren’t important, but that individuals and interactions are more important. But all too often I hear the horror stories from colleagues where the PHB‘s are more concerned about the processes and tools, their charts and graphs, than well… shipping good software.

What I’m saying here is certainly not new. The fascination with today’s way of doing things and the view that it is the one true path to good code is a seemingly permanent part of the programming culture. But it has been greatly abetted by the legions of Agile consultants. By stressing the practices, they have corrupted what Agile was about. It’s important to remember that the Agile manifesto stated values, not practices. Immediately, though, values were translated into programming practices by consultants and, quickly, the former was lost. One of the original formulators of the manifesto, Dave Thomas, whom I interviewed this week, states his realization that a month after the manifesto was written it was already being corrupted: “…it got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it’s a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise.”

What’s interesting in Thomas’s account is the view that Agile was a personal practice. Implicit is a personal way of orienting oneself towards a development process that accepts, even welcomes, change.

From Andrew Binstock’s “The Corruption of Agile”.

Agile can be a good thing, but it’s a good thing to have as principles, as personal practice. It’s more “spiritual” than “structural” if you will.

And once someone starts putting more emphasis on the “right side” items more than the “left side”, well… you just keep yourself on the principled path.

Leave a Reply