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.)
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:
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!]