Code Craft Bootstrapped

I’ll be blogging about this soon, but just wanted to share some initial thoughts on a phenomenon I’ve observed in very many development teams. A lot of teams confuse their tools with associated practices.

“We do TDD” often really means “We’re using JUnit”. “We refactor” often means “We use Resharper”. “We do CI” often means “We’re using Jenkins”. And so on.

As two current polls I’m running strongly suggest, a lot of teams who think they’re doing Continuous Integration appear to develop on long-lived branches (e.g., “feature branches”). But because they’re using the kind of tools we associate with CI, they believe that’s what they’re doing.

This seems to me to be symptomatic of our “solution first” culture in software development. Here’s a solution. Solution to what, exactly? We put the cart before the horse, adopting, say, Jenkins before we think about how often we merge our changes and how we can test those merges frequently to catch conflicts and configuration problems earlier.

Increasingly, I believe that developers should learn the practices first – without the tools. It wasn’t all that long ago when many of these tools didn’t exist, after all. And all the practices predate the tools we know today. You can write automated tests in a main() method, for example, and learn the fundamentals of TDD without a unit testing framework. (Indeed, as you refactor the test code, you may end up discovering a unit testing framework hiding inside the duplication.)

Talking of refactoring, once upon a time we had no automated refactoring tools beyond cut, copy and paste and maybe Find/Replace. Maybe developers will grok refactoring better if they start learning to do refactorings the old-school way?

And for many years we automated our builds using shell scripts. Worked just fine. We just got into the habit of running the script on the build machine every time we checked in code.

These tools make it easier to apply these practices, and help us scale them up by taking out a lot of donkey work. But I can’t help wondering if starting without them might help us focus on the practices initially, as well as maybe helping us to develop a real appreciation for how much they can help – when used appropriately.

Author: codemanship

Founder of Codemanship Ltd and code craft coach and trainer

One thought on “Code Craft Bootstrapped”

  1. My understaning has been that the C3 project didn’t invent and start doing TDD until after Kent wrote the SUnit tool.
    I think that “rolling your own tools” puts a high “barrier to entry” to using the practices. I think that the common availability of tools makes it much easier to adopt the practices.
    That many people confuse “tool X enables practice Y” with “I’m using tool X, therefore I must be doing practice Y” is a problem of the human condition. Maybe we could help people detect that they’re in these bad situations. But I suspect that many are strongly motivated to maintain their comforting delusions, rather than face the consequences of their shortfall.

    “It is difficult to get a man to understand something when his salary depends upon his not understanding it.” – Upton Sinclair

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s