Recently, I spoke with a very intelligent individual who's done it all in the software industry. The topic of deployments came up, and predictably, I began to advocate continuous deployment.
"We'll make mistakes, but I'd much rather our mistakes come from us going too quickly than us going too slowly," I said.
He smiled when I said that. "That reminds me of the distinction between function and purpose," he said.
I looked at him blankly. Do what now?
"Think about the brakes on a car. What's the function of car brakes? To slow down the car. What's the purpose, though?"
I thought for a moment. "Hmm, to save your life?"
"Close. The purpose of brakes is to allow you to drive fast."
Think about any practice we employ to build great software: unit tests, code reviews, continuous integration, and a zillion other things. As developers, we understand the function of all those very well, but I think we often forget about the purpose.
Let's pick on unit tests for a minute. What's the function of unit tests? They allow us to verify that software behaves the way we expect it to, in an automated manner. What's the purpose of unit tests, though?
The purpose isn't so you have great code coverage numbers or the warm, fuzzy feeling you get when you see them pass after a change or the awesome blog posts and tweets you can publish about your sweet testing culture. It's pretty much the same purpose as brakes on a car: writing unit tests allow you to go fast. (In fact, I'd say they allow you to go fast the right way.)
I actually think most good development practices share that same purpose. Sure, you're doing completely different things when you're writing a unit test versus reviewing someone's code versus scripting out your deployment process, but they all lead to the same result: better software, done faster. If you find yourself following a practice that doesn't share that purpose, you're following the wrong practice.
I think this distinction is important to remember. The next time you find yourself spending hour after hour debating methodology, remember the purpose behind what you're doing and try not to get swept away in the function.