The Business Case for Craftsmanship

When we talk about craftsmanship, there’s lots of agreement “that sounds good” (mostly from programmers) and a bit of “but why are you taking time out of your day to #{interesting activity}?” (mostly business types).

What do we mean by ‘craftsmanship’

Software craftmanship is about becoming better programmers – it’s people centered. And ideally, that ultimately reflects on their codebase as readable, maintainable, and testable code.

Readability and maintainability makes the codebase good for teams, and prevents the spiral into decay of a “code and fix” approach. Testable code is also usually readable and maintainable, but specifying testable suggests that one, you better be testing, and two, you care about code performance (and easily knowing if you accidentally broke something).

Reality

Not everyone works in a position where we the general rule is to “do things right the first time” or where the idea of taking work time to improve oneself is accepted as a great idea. If this sounds totally foreign to you, count yourself lucky. Many people who work in situations where they need to constantly justify the time spent on a project/activities.

(If you want ideas of things to do in your workplace to help yourself and your colleagues improve, I highly recommend Sebastian Hermida’s Zombies in My Workplace.)

By creating an environment that supports craftsmanship, your business gets:

– Better code runs faster (performance factor)

– More efficient bug fixes – it takes less time to solve problems because it was done right, and is actually understandable and tested (maintinability factor)

– A sticker workplace – learning more makes people stickier. It makes them feel smart. It connects them with smart people. People leave companies when they feel like they aren’t learning, or their learning has plateaued. (the people factor)

When non-business types take issue with the pursuit of craftsmanship, there’s often a confusion between “good code” and “good style.” Basically, it’s defensiveness — “You can’t tell me how to write code!” Sure, whatever.

Style is very subjective. You could argue code is subjective as well — but code also has that handy fact that sometimes it is literally better. My code runs faster/is smaller/more efficient than yours? My code wins. Good is not the same as style.

Conclusions

Awesomely, I don’t have this problem at work, but we did have an interesting conversation about it recently — what do we mean when we say certain things are “better”? Can you prove it? How do you?