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 Customer

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.

David Starr