Software Craftsmen or what?

Dan North published a shot across the bows at the signers of the Software Craftsmanship Manifesto. Apparently me living in a snow cave the last couple of years has been bad for my geek cred, I wasn’t even aware of it. But the sentiment it tries to encapsulate has been around for a long time. We all generally agree our industry sucks because we consistently under estimate, under deliver or outright fail on software projects. These software craftsmen believe that, as best I can tell anyway, the reason for this is that our ranks are made up of either ivory tower software as art sorts, epitomized by certain speakers, writers and open source gurus, or of “I am only in this for the money” types that hack their way through the coding until systems collapse of their own weight. Or something like that. What is needed is more of a middle ground with standards of professionalism, quality, collaboration and so on, rather like we think of building craftsmen in other professions.

Dan North’s post has garnered a lot of attention, one because he is the well known, self-effacing and generally good guy that he his, and two because he shoots poo over the whole manifesto. He believes that the people who buy software don’t really give a hoot about what goes into the software, it is purely the utility of it that they care about, and for the least cost:

“Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.)”

His very lengthy elaboration is both entertaining and thought provoking. So whats not to like? The last line in his leader, the one about appreciating boiler controls hints at it. I disagree that the buyers can’t really see what’s going on behind the scenes enough to tell if the the system is quality or not.

Users are enormously attuned to how systems work for them, or against them. They largely experience the design and quality through user interfaces, but not exclusively. Right at their fingertips they can tell if they have to jump from system to system to find what they need to get their jobs done. They can tell if the information being shown is accurate, because they have to live with the consequences of it not being accurate. If the information is delayed, they have to live with that. If the system is incomplete requiring manual workarounds or business processes, they have to live with that. If the system represents information in a way not consistent with how the users think of that, say a contact has a company vs a company has contacts in a sales process, they have to fight with the cognitive dissonance. If the system throws errors, they deal with that. If fixes and modifications take months to deliver, or are years between deployment they have to live with that. If the system is down a lot, or slow, or inconsistent in how they have to use it they notice that. And they think it sucks!

Most of the things that the Software Craftsmanship true believers are trying to accomplish are directed at just these kinds of problems in development. Just like you choose a certain quality of concrete and method of construction for a bridge, you need a certain qualities of development practices to consistently build applications and systems. When my plumber told me he wanted to use copper pipes because they were quieter than PVC, I believed him, and they were. When I say we should require developers to not build SQL in line to prevent a common security breach, I want to be trusted with that.

Dan would not disagree with this. He is actually more worried about the craftsmen becoming to caught up in the glory of it all:

“So here’s my concern with the idea of Software Craftsmanship. It’s at risk of letting programmers’ egos run riot. And when that happens… well, the last time they went really nuts we got Web Services, before that J2EE. They convinced the British government that they wanted an uber-database to store Everything Ever About Everyone. You see where I’m going?”

But that isn’t what they are doing as best I can tell. Perhaps some are, and to be sure, developers putting technical concerns over outcomes is an issue in our field. But on the flip side, exhibit A, Corey Haines giving typing classes to improve productivity. Brilliant! I am always amazed when I see developers that don’t know how to use a text editor well. If you can’t manipulate text really well, you certainly aren’t going to take the time to refactor rotten code. As a jazz guitar player, if can’t play Donna Lee at 240 bpm, I probably can’t get a gig. Should be the same with typing.

The real problem is the manifesto itself which really doesn’t say anything concrete. Signing it is really just aligning yourself with a School of Thought, utterly unquantifiable or indicative of outcomes. Dan’s most salient point is that we have no way of knowing to what degree if any a person is a craftsman or not, and the manifesto helps in no way at all. On this point I agree completely.

There is a another point on productivity there, blasted in another post I thought was funny in an Angry Coder, profane style, but I’ll hit that another day.


Comments are closed.