Software Craftsmanship

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.

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!]