On Craftsmanship, Part 1
In the 2005 movie, Kinky Boots, shoe maker and factory owner Charles Price visits one of his customers who has begun buying fewer shoes.
Shoe Store Owner: "Look at these shoes I can get from Taiwan. They are 1/2 the price I pay for your shoes and I can sell them for the same price."
Price: "But these shoes are poorly made. Look at the flimsy materials and shoddy stitching. They won’t last a year before the customer will need to buy another pair."
Shoe Store Owner: "Exactly."
This clash of craftsman and businessman is an old one. We can even imagine examples of this contention in early agriculture.
"My fruit is the richest, plumpest, ripest available."
"But how much of it can you grow?"
The shoe maker is critical of poor stitching. The farmer is proud of his quality. The balance of pressing business concerns versus quality are as present in those examples as they are in software development today.
It isn’t typically the businessman who sees the value in the well-crafted item. It often isn’t even the customer. How often have you been willing to trade convenience for quality when shopping for a last minute gift? At 8PM on Christmas-eve, that gift card to iTunes can look awfully tempting.
Sometimes quality is the driving influencer in buying decisions. When the cost is higher, quality often becomes more important. Do you buy the KIA or the Toyota? Do custom build a home or buy one in a cookie-cutter neighborhood? Often, we pay for as much quality as we can afford with big ticket items and settle more easily for crap when the cost is less.
Charles Price was aghast at his customer’s attitude. "How can this person value my craft so little?" he surely asked himself.
We ask ourselves this question all the time as software developers. When your Product Owner approaches you to inquire about your services for delivering new software (features, defect fixes, whatever), what is the real question they want answered?
"How long will it take?"
You know its true. That is the #1 question asked of non-software developers about our work. Customers don’t ask about the ORM tooling. They don’t ask about the IDE. Only occasionally do they ask about quality. When was the last time a customer asked you, "And what measures will you take to ensure that this software is created well?"
The Craftsman Mentality
It is the plight of the craftsman to consider primarily the quality and execution of his or her work. It is the craftsman who can’t sleep at night because the stitching isn’t right, the apples are too small, or the data access layer is tightly coupled.
We can see the difference between developers and craftsmen in how well we sleep at night after making bad decisions or big mistakes. In short, craftsmen care. These are people who have not only the skills, but the mentality of perfection that is almost crippling to the businessman.
In fact, it is common for successful entrepreneurs to feel distraught when their ideas become successful to the point of maturing beyond their control. Often, this is because something once considered special, a craft if you will, has been grown into a commodity. Rarely does the original inventor of a new product make a good CEO for the company that makes and sells it.
People we see as genius are often hyper-craftsmen. These people are dually admired and derided for the single-mindedness of purpose that propels their obsession. This is point of Atlas Shrugged, which you undoubtedly consumed as a freshman in college and then behaved like an arrogant a-hole for a week afterward. But the story makes a valid point: Genuine quality of craft can only be achieved through obsessive pursuit.
Tools of the Craft
Software developers have better tooling today than ever before. ORM tools are so readily available not using them could almost be considered negligence. IoC containers are numerous and free. Unit Testing frameworks are falling out of your pockets. But, who are these tools for? These are tools built by craftsmen for craftsmen to be used in execution of our work for customers.
We know these tools are good. They make our work better, not just easier. Customers don’t get that. Now what?
It is common for craftsmen to embrace tools they want to try and discard those that would be held in low esteem by other craftsmen. The more arcane, the better. It just so happens that in our field, arcane is often translated as newer.
The disparaging talk about "drag and drop development" comes to mind. Controls such as WF activities are merely higher level abstractions of curly-braced code. The end result of using a visual programming tool versus a cryptic abstraction driven through XML configuration is often the same. FinalBuilder and MSBuild or NAnt, for instance.
However, when looking at a beautiful piece of completed furniture, does it matter whether the timbers were but on a table saw or hewn by hand with manual planes over 2 weeks? What probably makes the most difference is which tool the craftsman was more comfortable with. Maybe he’s Amish and a power tool is just not in the works.
So, Who Wins?
Finding the customer pitted against the craftsman on questions of quality and technique is a common drama. How does the craftsman deal with this? What options are there for the artisan who wants to earn a living, stay true to the craft, and have some degree of material success?
Some craftspeople find appreciating patrons for their work. This is why there are boutique software development shops, rare and expensive whiskies, paint and body shops that cost more that Maaco, and upscale restaurants. The obvious downside to this path is easily seen in today’s economic climate. I am just guessing, but I bet there are fewer $6,000 custom poker tables being sold today than 3 years ago.
Another common path is that of least resistance. The embattled craftsman often surrenders to the constant battering received at the hands of those who hold the money. This is an age-old story retold in movies, music, and literature frequently (Ozzie, can you hear me?).
At what point in the development process did I compromise my integrity? Was it when I started writing code before I knew what I needed to make? Was it when I bypassed writing unit tests? Was it when I failed to automate the build? Or, how about when I bound a list box directly to a dataset? Was it simply when I stubbed the object to generate the unit test?
It may be unclear when integrity surrendered, but looking at the work in totality it is obvious that the sell was made.
Oh, God. That’s Depressing
Balancing ignorant obsession and economic viability is the real thing we all do, albeit with some distaste. Being able to "talk to the business" is considered a decreasingly rare talent in I.T. because we can all understand the need to be effective within our organizations. Most of us work in places where our work is seen as a means to an end, and this means we struggle to stay true to the ideals that made us want to write code in the first place.
Finding a reasonable balance for these diametrically opposed concerns even has a name. It is called being a professional.
3 thoughts on “On Craftsmanship, Part 1”
I have only ‘been agile’ for a short period of time (less than 6 months) and was recently offered a small part-time project. It involved a codebase that was very far from pattern- and OO-oriented. Very small application that solved a little problem.
Long story short I had to dismiss the project for two reasons. It would involve a huge compromise in quality from my current standards and I wouldn’t be able to sleep at night after having completed it. When you know a better road it is hard to take the bumpy one again.
For now I am unable to make that compromise as I’m still learning the ‘agile craft’. I have to use abstractions, patterns and agile testdriven practises exclusively long enough to be able to determine when it is okay to defer from the path. If I compromised now, I would lay awake for days afterwards figuring out improvements of the code. It would be more damaging to my learning curve than any amount of poorly chosen patterns ever could be.
I discussed it with a colleague (who offered the project) and I have to admit – at current I’m not competent enough to take the job – I cannot yet take a poorly written codebase and refactor it enough to be able to fix the problems they have without introducing new bugs. The funny part is that had he asked me 6 months ago, I would have readily accepted the job – contributed to a poor code base with more poor code – and I would have slept soundly at night.
The funny thing is – if you ask me 6 months from now – I might accept the offer, contribute good code to a poorly written codebase just using refactorings. Because there is a hidden business niche here. When you are asked to ‘repair’ an old codebase, you at the same time have the opportunity to introduce ‘low hanging fruit’. Small refactorings that will make the next many ‘repairs’ easier. The customer will see an increasingly stable product and will ask you to fix it the next time.
Customers may not understand code quality, but they can still ‘feel’ software quality when they use it. Every customer has had bad experiences with faulty software. They may stray to other suppliers for a short period of time, but they will eventually return remembering the ‘friction-free period’. It is not always the better businessplan to be the cheapest. Honest business men (and often very succesfull ones) will know how to sell quality. They know that customer loyalty is what will keep them alive in 5-10 years in the future.
If you cannot explain to a customer why they should invest in quality software – you are a poor businessman and thus a poor salesman. It is your fault – not the customer’s. You are the expert – he is (at best) the lay-man.
It hinges on the customer as to whether they’ve been “stung” by cheap software before or not. Simply put, if you’re in the realm of green-fields development, price & speed rule, not quality. Vendor (A) quotes $400k and 6 months, you quote $750k and 12 months to deliver a higher quality solution, chances are they’ll pick (A) 90% of the time. I guess you can feel morally sound that they’ve chosen to make a mistake, but that doesn’t pay he bills.
Going cheap they’re choosing to roll the dice. Maybe they get a good enough product and everything’s rosy. Chances are they get some grade of crap that was slapped together. Provided they had a stable enough product to go to market with they’ll soon understand that maintaining and expanding the functionality of that product is now proving troublesome, slow, and expensive. Now enter the “Agile Elite” to clean up the mess and produce some low hanging fruit. Pull it off and maybe, just maybe they’re convinced that for Green-field mk II project it might be better to try quality over quantity… But pull up the muck boots for some hard yards through the sludge. 😉
My $0.02 of exp.
Comments are closed.