January 12, 2011
Why Software Craftsmanship Is Not Just About "Beautiful Code"After various philosophical discussions about the relationship between craftsmanship, clean code and customer satisfaction, I felt compelled - like the bighead I am - to share my thoughts.
To me "craftsmanship" is about building it right. Whatever we're asked to build, we do the best job possible.
If a customer asks for the wrong thing, that's no more an issue of software craftsmanship than if they'd asked a furniture craftsman to build them a red sofa and then decided they didn't like the material they'd chosen.
Building the right thing is, of course, very, very important. Logically, there's more initial value in a cruddy implementation of something genuinely useful than in a watertight, squeaky-clean implementation of something useless.
But the relationship between building the right thing and building it right is as complex and nuanced as the relationship between programmers and customers. There's no crisp, clear dividing line between those concerns or between those responsibilities. Customers cannot be expected to know exactly what they need right from the start, and programmers cannot be expected to deliver the perfect solution first time.
That is why we have learned to iterate. To me, that's why craftsmanship is important. Given that what we deliver will almost certainly need to change, we'd better make sure what we deliver is easy to change.
It is our responsibility to help our customers figure out what they really need by firstly delivering exactly what they ask for and doing it in a way that doesn't prevent them from changing their minds afterwards.
If there's a risk that well-crafted code comes at the expense of satisfied customers, we would see evidence for this. Is there a correlation between code cleanliness and customer dissatisfaction?
Do programmers who dedicate themselves to improving in the technical practices (because programming is a technical practice, in case you were wondering) tend to be blinded to the customer's needs?
To me, that sounds like "musicians who strive to perfect their chops don't play with feeling". And there's absolutely no evidence of that.
What's certainly true is that programmers who don't strive to improve at programming tend to dissatisfy customers by delivering software that is unreliable and expensive to change, regardless of what it does. Sure, the customer may be delighted with the first release - hooray for our side - but considerably less delighted when the bug reports start flooding in and we have to tell them how long a second release is going to take.
Because, you see, all those horrendous legacy systems we end up waist-deep in were once bad jobs of something useful. By delivering buggy, unmaintainable software that the customer could use, we effectively hung a millstone around their necks, and we know from experience that the pain comes sooner than we think.
I'm not aware of anyone in the craftsmanship movement who has not devoted considerable attention to the problem of building the right thing. I know I've agonised over it for years, coming up with practices and techniques for defining customer business goals, for understanding the business context in which software is to be used, and for testing our assumptions about what should work.
But we will be at a disadvantage if the mythology of software craftsmanship - that it's an elitist movement of prima donnas who insist on writing beautiful code at the exclusion of all else - takes hold, especially among customers.
So it's important that we lay this ghost to rest. If you're coming to SC2011, you will meet 150 passionate programmers who very much care that the customer gets what they need, and that is why they take their craft so seriously.
ADDENDUM: Someone on Twitter commented that they would happily put up with code that isn't beautiful as long as it worked. I think, again, the relationship between code cleanliness and correctness isn't all that clearcut. The more complex and incomprensible code is, the easier it is to get wrong. Dependencies also play a role here. If we don't manage dependencies, then the chances of inadvertantly breaking other parts of the code while working are significantly increased. It's worth remembering that many changes get made to code before even the first release. Maintainability of codce written on Day #1 can be a factor in our productivity on Day #2.
Posted 7 years, 7 months ago on January 12, 2011