Software Craftsmanship

S

My good friend and colleague at Elcom, Angus McDonald (aka Falkayn), and I have been chatting about ways to improve the software processes at work. He’s taking over many of the responsibilities I’ve held – now that I’m moving on – and is a considered thinker.

Angus is much more Agile focussed than me, and recently lead a very useful retrospective for us at Elcom. In a recent discussion we’ve been looking at the issue of quality, and in particular how we can improve it. Interestingly, this topic has come up in a number of talks I’ve had with various parties recently. Quality, as a topic, seems to be making a resurgence (eg Microsoft and Apple have both indicated strategies of better quality in preference to bulging feature sets – consider Windows 7 for example.)

 

The book

During the chat Angus recommended Pete McBreen’s classic book – Software Craftsmanship. Its been around for a while now and is reasonably well known.

Software Craftsmanship by Pete McBreen

After reading it, I have to say that this book has come close to rocking my world.

This has totally changed my outlook on software development. If you haven’t read it then you probably should. If I were to summarise it I’d say this:

Let’s make a stand against ‘good enough’ software. Let’s build quality. Let’s consider software development as a craft.

Easier said than done right? For too many years I’ve been a realist – you know, mature (and smug) enough to realise software always has bugs and we have budgets to meet (as the saying goes: money, time, quality – pick 2). Those pesky idealists with their goals of striving for perfection obviously haven’t spent enough time in the real world…

But, I’m changing my tune now.

Just how do we build quality? According to McBreen its about embracing the concept of software craftsmanship*. It’s about seeing software development as a craft, and not as a production line. In a nutshell: it’s about understanding that developers need to think. As McBreen notes:

“Students learn about the requirements, without ever taking the time to think about where the requirements come from or learning the facilitation skills necessary to elicit them from the user communities.” (p32)

Now, the purpose of this post isn’t to cover McBreen’s argument (you can read the book for that), but there is one point (of the many he makes) I want to highlight.

A key contributor to mastering your craft is in knowing your technology and toolset extremely well. It’s much harder, for example, to build a high quality application if you’re spending most of your time trying to understand the latest new fangled technique. That’s not to say that new technology and craftsmanship are necessarily mutually exclusive, but they can often compete. After all, if you don’t know your technology well, you can fall into the trap of letting what little you do know about the technology dictate how the requirements are implemented (with the obvious limitations and quality issues that will follow).

Here’s why its giving me pause for thought:

 

VBA developers

This weekend I’m presenting at Office DevCon on the topic of ‘VSTO for VBA Developers’.

It struck me as I’ve been preparing, that many VBA developers are indeed software craftsmen (or craftswomen). They’ve been working intimately with their technology for years (decades even) and they’ve seen countless real world VBA implementations. Quite simply, they have a wealth of VBA experience, skills and applied understanding that has seen many of them master their craft.

So, with that capability, why would they want to move onto something completely different… like VSTO?

Or, consider FoxPro. Having come from the FoxPro community, I’ve experienced first hand how many of the VFP developers are master craftsmen in the truest sense. How can you compete with more than 20 years of in-depth experience with essentially the same tool, coupled (for many practitioners) with working in the same industry (eg finance or medical or manufacturing)?

Sure, the newer tools allow you to do more and different things, but they don’t magically turn you into a craftsman.

Back to our VBA developers. What can I possibly say that will make them comfortable with the thought of VSTO? Well, as it turns out there’s plenty to offer (the magic of interop is a key one, and I’ll be covering my presentation in a later post) but that’s not the point.

The point is, they should be very wary of any new technology – if it is going to adversely affect quality. They would be right to question the need to change.

 

Time to stand up

Don’t get me wrong, this isn’t a post about getting stuck in the past. After all, software development by its very nature is a constantly changing field, and we should all be working hard to stay current. No, this is a post about prioritizing.

We must constantly remind ourselves, that regardless of the amazingness of the latest tools, we need to ensure our focus is first and foremost on mastering our craft. We must renew our commitment to quality. We must resume educating our clients about the longer term cost savings of quality software. We must not let our industry fall further into the mire of ‘good enough’ software.

McBreen’s book was relevant when he wrote it way back in 2002 (yes, 6 years is an eternity in IT). Today, more than ever, it is a necessity.

 

[* Note: craftsmanship is gender neutral – just in case some well meaning soul thinks we should be referring to it as craftspersonship!]

5 comments

Leave a Reply to Paul Pagel Cancel reply

  • I agree, a lot of what Pete McBreen talks about are the same behaviors I have seen the developers I admire for years. It is good to affirm though that this whole craft thing is behind it. It also puts us as developers in control of everything we are experts in.

    Practicing software as a craft is the only way I know of how to do it well.

    As an addendum to your note, Micah Martin goes into the "Definition of a craftsman", addressing the simple axioms like gender neutrality. http://blog.8thlight.com/articles/2008/9/22/definition-of-software-craftsman

  • I agree, a lot of what Pete McBreen talks about are the same behaviors I have seen the developers I admire for years. It is good to affirm though that this whole craft thing is behind it. It also puts us as developers in control of everything we are experts in.

    Practicing software as a craft is the only way I know of how to do it well.

    As an addendum to your note, Micah Martin goes into the "Definition of a craftsman", addressing the simple axioms like gender neutrality. http://blog.8thlight.com/articles/2008/9/22/definition-of-software-craftsman

  • I realize this is an old post – I came across it while looking up “Good enough software”.

    Can you elaborate on this sentence “We must resume educating our clients about the longer term cost savings of quality software.”

    A couple of questions.
    – What are the specific points you would use to educate clients?
    – What happens if what you try to educate the customer on quality and they don’t actually care about the same things as you? IE – What if your idea of quality is different than theirs?
    – How do you talk about quality in a meaningful way?
    – Even if your team could produce software at a higher quality, and actually manages to get costs savings by doing this, do you think that cost savings would be passed down to the customer?

By Craig Bailey

Archives