Clinton Begin recently did a talk at a local Java users group, called “Ruby Rebuttal“. While I like Ruby, I know that Clinton is tired of some of the hype surrounding the language, and the calls and predictions of Java’s impending death at its hand. I was unable to attend his talk, but I particularly liked this part of his abstract:

So what’s the problem? We’ve forgotten how to write good software. Instead, we choose to blindly follow “best practices” and “patterns” by simply stuffing what used to be good code into reams of XML and annotations.

I agree. I don’t really care about Ruby vs. Java, or vi vs. Emacs, or “Agile” vs. “non-Agile”, etc. etc. etc. debates. Furthermore, hype does little to impress me. Like Clinton, I find myself turned off by excessive hype, and it makes me want to run in the opposite direction. What impresses me are people who have a position on an issue and aren’t afraid to speak their minds. What impresses me even more are skilled practitioners with a track record. I know Clinton–we’ve worked together–and I have a great deal of respect for him. Reading that section of his abstract just raised him up a few notches in my eyes.

I would take what Clinton said one step further. We also stuff what used to be good practice for development teams into a process. We then hold this process up like some mystically-endowed talisman, and through ritual and jargon create a kind of priesthood. The process might be home-grown, it might be “Agile,” or it could be anything that seems fashionable at the time. There are the us, and there are the “unenlightened” them. (Sometimes, as the previous links show, the “enlightened” helpfully point out the “them” in the form of a joke. How this attempt at parody does anything constructive is beyond me.) I might like or dislike a particular process, but if it is working for the team, that’s what really matters. A process, no matter what it is, is our servant, a tool to help us realize our goals.

When we lose sight of the goals of the business, it’s easy to hide behind a process, a framework, or a language. “Yeah, the product sucks, but we followed the 12 Practices of XP! Look at this scatter chart! We did everything we could!” or or “It would have worked if we had used Java!” or “We used XML! It had to work!” Programming languages, frameworks, development processes and best practices can all be used as shields.

What Clinton touches on reminds me of a blog post by Robert Martin: I’d rather use a socket. Uncle Bob says:

I think the industry should join frameworks anonymous and swear off gratuitous framework adoption. We should all start using sockets and flat files instead of huge middleware and enormous databases — at least for those applications where the frameworks and databases aren’t obviously necessary.

The first time I read Martin’s blog post, Clinton and I were both looking at a design document. A challenge for the proposed system was performance, but it had so many options of distributed frameworks it looked like the latest ad for a Service Oriented Architecture consulting company. Clinton turned to me and said: “If performance is a big deal, why are they looking at a distributed system? Going to disk is going to be much faster.” At that moment I knew Clinton and I were going to get along just fine.

I see the same kind of behavior Clinton and Robert Martin describe when it comes to processes – Agile or otherwise. Paraphrasing Robert Martin: I think the industry should join processes anonymous and swear off gratuitous process adoption.

We should all start analyzing what our processes are doing for us, and only allowing the practices that work for your team, in your context to stick around. We need not hide behind “Agile this” or “XP that” or “CMM something-or-other”, but proudly display our skill, and more importantly, our handiwork to satisfied and impressed customers.

We need to write great software, and continuously improve on whatever languages, frameworks and processes get us there. Whatever we do, we must be aligned with the goals of the business, and take the skills of the team members, as well as the corporate culture into account when we adopt a tool. We need to use the tool that serves us, whether it is a programming language, an IDE, a framework or a process. Leave the religiosity to medieval scholars. If we lose sight of what we’re in business for in the first place, our processes will just end up as hollow ritual.