Last Thoughts on "Craftsmanship"

TL;DR Live craftsmanship, don't preach it. The creation of a label serves no
purpose other than to disambiguate and distinguish. If we want to hold people accountable
to some sort of "professionalism", then we have to define what that means. I found
Uncle Bob's treatment of my blog heavy-handed and arrogant. I don't particularly want
to debate this anymore; this is my last take on the subject.

I will freely admit, I didn't want to do this. I really didn't. I had hoped that after
my second posting on the subject, the discussion would kind of fade away, because
I think we'd (or I'd, at least) wrought about the last few drops of discussion and
insight and position on it. The same memes were coming back around, the same reactions,
and I really didn't want to perpetuate the whole thing ad infinitum because
I don't really think that's the best way to reach any kind of result or positive steps
forward. I'd said my piece, I was happy about it.

Alas, such was not to be. Uncle
Bob posted his thoughts [1], and quite frankly, I think he did a pretty bad job of
hearing what I had to say, couching it in terms of populism (I stopped counting the
number of times he used that word at six or so) even as he framed in it something
of his own elitist argument.

Bob first points us all at the Manifesto
for Software Craftsmanship [2]. Because everyone who calls themselves a craftsman
has to obey this manifesto. It's in the rules somewhere. Sort of like the Agile Manifesto--if
you're not a signatory, you're doing it wrong.

(Oh, I know, to suggest that there is even the smallest thing wrong with the Agile
Manifesto borders on heresy. Which, if that's the reaction you have, should be setting
off a few warning bells in your head--something about replacing dogma with dogma.)

And you know what? I actually agree with most of the principles of the Craftsmanship
Manifesto. It's couched in really positive, uplifting language: who doesn't want "well-crafted"
software, or "steadily-increasing value", or "productive partnerships"? It's a wonderfully-worded
document that unfortunately is way short on details, but hey, it should be intuitively
obvious to anyone who is a craftsman, right?

See, this is part of my problem. Manifestos tend to be long on rhetoric, but very,
very short on details. The Agile Manifesto is another example. It stresses "collaboration"
and "working software" and "interactions" and "responding to change", but then people
started trying to figure out how to apply this, and we got into the knife-fights that
people arguing XP vs. Scrum vs. Kanban vs. your-homebrewed-craptaculous-brand-of-"little-a"-agile
turned into brushfire wars. It's wonderful to say what the end result should be, but
putting that into practice is a whole different ball of wax. So I'm a little skeptical
any time somebody points to a Manifesto and says, "I believe in that, and that should
suffice for you".

Frankly, if we want this to have any weight whatsoever, I think we should model something
off the Hippcratic Oath [3],
instead--it at least has prescriptive advice within it, telling doctors what they
can and cannot (or, perhaps worded more accurately, should or should not) do. (I took
something of a stab at this six
years ago [4]. It could probably use some work and some communal input; it was a first
iteration.)

Besides (beware the accusation coming of my attempt at a false-association argument
here, this is just for snarkiness purposes!), other
manifestos [5] haven't always worked out so well.>

So by "proving [that I misinterpreted the event] by going to the Manifesto", you're
kind of creating a circular argument: "What happened can't have been because of Software
Craftsmanship, because look, there, in the Manifesto, it says we don't do that, so
clearly, we can't have done that. It says it, right there! Seriously!"

The Supposed "Segregation"

Bob then says I'm clearly mistaken about "craftsmen" creating a segregation, because
there's nothing about segregation in the manifesto: any intimation of
those who "get it" vs. those who don't; or any mention of the "right" tools or the
"right" way. Indeed, what I see instead is a desire to steadily add value by writing
well-crafted software while working in a community of professionals who behave as
partners with their customers. That doesn't sound like "narcissistic, high-handed,
high-minded" elitism to me. Hold on to that thought for a bit.>

Bob then goes on an interesting leap of logical assumption here. He takes my definition
of a "software laborer": "somebody who comes in at 9, does what they're
told, leaves at 5, and never gives a rat's ass about programming except for what they
need to know to get their job done [...] who [crank] out one crappy app after another
in (what else?) Visual Basic, [that] were [...] sloppy, bloated, ugly [...] cut-and-paste
cobbled-together duct-tape wonders." and interprets it as Now
let's look past the hyperbole, and the populist jargon, and see if we can identify
just who Ted is talking about. Firstly, they work 9-5. Secondly, they get their job
done. Thirdly, they crank out lots of (apparently useful) apps. And finally, they
make a mess in the code. The implication is that they are not late, have no defects,
and their projects never fail. That's weird. I go back and read my definition
over and over again, and nowhere do I see me suggesting that they are never late,
no-defect, and never-fail projects. Is it possible that Bob is trying to set up his
next argument by reductio
ad absurdum [6], basically by saying, "These laborers that Ted sets up, they're
all perfect! They walk on water! They must be the illegitimate offspring of Christ
himself! Have you met them? No? Oh, then they must not exist, and therefore his entire
definition of the 'laborer' is whack, as these young-un kids like to say.">

(See what I did there? I make Bob sound old and cantankerous. Not that he would do
the same to himself, trying to use his years of experience as a subtle bludgeon to
anyone who's younger and therefore less experienced--less professional, by implication--in
his argument, right? Programming is barely 60 years old. I, personally,
have been programming for 43+ of those years. Oh.)>

Having sort of wrested my definition of the laborer away from me, Bob goes on: I've
never met these people. In my experience a mess in the code equates to lots of overtime,
deep schedule overruns, intolerable defect rates, and frequent project failure --
not to mention eventual redesign. Funny thing. I've seen "crafted" projects
that fell to the same victims. Matter of fact, I had a ton of people (so it's not
just my experience, folks, clearly there's a few more examples out there) email and
comment to me that they saw "craftsmen" come in and take what could've been a one-week
project and turn it into a six-month-or-more project by introducing a bunch of stuff
into the project that didn't really need to be there, but were added in order to "add
value" to the code and make it "well-crafted". (I could toss off some of the software
terms that were cited as the reasons behind the "adding of value"--decoupled design,
dependency injection, reusability, encapsulation, and others--but since those aren't
in the Manifesto either, it's easy to say in the abstract that the people who did
those projects weren't really adding value, even though these same terms seem to show
up on every singe project during architecture and design, agile or otherwise.)>

Bob goes on to sort of run with this theme: Ted has created a false dichotomy
that appeals to a populist ideology. There are the elite, condescending, self-proclaimed
craftsmen, and then there are the humble, honorable, laborers. Ted then declares his
allegiance to the latter... . Well, last time I checked, all I have
to do to be listed amongst the craftsmen is sign a web page, so "self-proclaimed"
seems pretty accurate as a title. And "elite"? I dunno, can anyone become a craftsman?
If so, then the term as a label has no meaning; if not, then yes, there's some kind
of segregation, and it sure sounds like you're preaching from on high, particularly
when you tell me that I've created a "false dichotomy" that appeals to a "populist
ideology": Generally, populists tend to claim that they side with "the
people" against "the elites". While for much of the twentieth century, populism was
considered to be a political phenomenon mostly affecting Latin America, since the
1980s populist movements and parties have enjoyed degrees of success in First World
democracies such as the USA, Canada, Italy, the Netherlands and Scandinavian countries. So
apparently I'm trying to appeal to "the people", even though Bob will later tell us
that we're all the same people. (Funny how there's a lot of programmers who feel like
they're being looked down on by the elites--and this isn't my interpretation, read
my blog's comments and the responses that have mushroomed on Twitter.) Essentially,
Bob will argue later that there is no white-collar/blue-collar divide, even though
according to him I'm clearly forming an ideology to appeal to people in the blue-collar
camp.>

So either I'm talking into a vacuum, or there's more of a divide than Bob thinks.
You make the call on that one.

Shall we continue? He strengthens his identity with, and affinity for,
these laborers by telling a story about a tea master and a samurai (or was it some
milk and a cow) which further extends and confuses the false dichotomy. Nice
non-sequitur there, Bob! By tossing in that "some milk and a cow", you neatly rob
my Zen story of any power whatsoever! You just say it "extends and confuses the false
dichotomy", without any real sort of analysis or discussion (that comes later, if
you read through to the end), and because you're a craftsman, and I'm just appealing
to populist ideology, my story no longer has any meaning! Because reductio ad make-fun-of-em is
also a well-recognized and well-respected logical analysis in debating circles.>
Oh, the Horror! ... of Ted's Psyche

Not content to analyze the argument, because clearly (he says this so many times,
it must be true) my argument is so weak as to not stand on its own (even though I'm
not sure, looking back at this point, that Bob has really attacked the argument itself
at all, other than to say, "Look at the Manifesto!"), he decides to engage in a little
personal attack: I'm not a psychoanalyst; and I don't really want to
dive deep into Ted's psyche to unravel the contradictions and false dichotomies in
his blog. However, I will make one observation. In his blog Ted describes his own
youthful arrogance as a C++ programmer... It seems to me that Ted is equating his
own youthful bad behavior with "craftsmanship". He ascribes his own past arrogance
and self-superiority with an entire movement. I find that very odd and very unfortunate.
I'm not at all sure what prompted him to make such a large and disconnected leap in
reasoning. While it is true that the Software Craftsmanship movement is trying to
raise awareness about software quality; it is certainly not doing so by promoting
the adolescent behavior that Ted now disavows. Hmm. One could argue
that I'm just throwing out that I'm not perfect nor do I need to profess to be, but
maybe that's not a "craftsman's" approach. Or that I was trying to show others my
mistakes so they could learn from them. You know, as a way of trying to build a "community
of professionals", so that others don't have to go through the mistakes I made. But
that would be psychoanalyzing, and we don't want to do that. Others didn't seem to
have the problem understanding the "very large and disconnected leap in reasoning",
and I would hate to tell someone with over twice my years of experience programming
how to understand a logical argument, so how about let's frame the discussion this
way: I tend to assume that someone behaving in a way that I used to behave (or still
behave) is doing so for the same reasons that I do. (It's a philosophy
of life [7] that I've found useful at times.) So I assume that craftsmen take the
path they take because they want to take pride in what they do--it's important to
them that their code sparkle with elegance and beauty, because that's how code adds
value.>

Know what? I think one thing that got lost somewhere in all this debate is that value
is only value if it's of value to the customer. And in a lot of the "craftsmanship"
debates, I don't hear the customer's voice being brought up all that much.

You remember all those crappy VB apps that Bob maligned earlier? Was the customer
happy? Did anybody stop to ask them? Or was the assumption that, since the code was
crappy, the customer implicitly must be unhappy as well? Don't get me wrong, there's
a lot of crappy code out there that doesn't make the customer happy. As a matter of
fact, I'll argue that any code that doesn't make the customer happy is crap,
regardless of what language it's written in or what patterns it uses or how decoupled
or injected or new databases it stores data into. Value isn't value unless it's value
to the person who's paying for the code.

Bob Discusses the Dichotomy

Eh, I'm getting tired of writing all this, and I'm sure you're getting tired of reading
it, so let's finish up and call it a day. Bob goes on to start dissecting my false
dichotomy, starting with: Elitism is not encouraged in the Software Craftsmanship
community. Indeed we reject the elitist attitude altogether. Our goal is not to make
others feel bad about their code. Our goal is to teach programmers how to write better
code, and behave better as professionals. We feel that the software industry urgently
needs to raise the bar of professionalism. Funny thing is, Bob, one
could argue that you're taking a pretty elitist stance yourself with your dissection
of my blog post. Nowhere do I get the benefit of the doubt, nor is there an effort
to try and bring yourself around to understand where I'm coming from; instead, I'm
just plain wrong, and that's all there is to it. Perhaps you will take the stance
that "Ted started it, so therefore I have to come back hard", but that doesn't strike
me as humility, that strikes me as preaching from a pulpit in tone. (I'd use a Zen
story here to try and illustrate my point, but I'm afraid you'd characterize it as
another "milk and a cow" story.)>

But "raising the bar of professionalism", again, misses a crucial point, one that
I've tried to raise earlier: Who defines what that "professionalism" looks like? Does
the three-line Perl hack qualify as "professionalism" if it gets the job done for
the customer so they can move on? Or does it need to be rewritten in Ruby, using convention
over configuration, and a whole host of dynamic language/metaprogramming/internal
DSL tricks? What defines professionalism in our world? In medicine, it's defined pretty
simply: is the patient healthier or not after the care? In the legal profession, it's
"did we represent the client to the best of our ability while remaining in compliance
with the rules of ethics laid down by the bar and the laws of the entity in which
we practice?" What defines "professionalism" in software? When you can tell me what
that looks like, in concrete, without using words that allow for high degree of interpretation,
then we can start to make progress towards whether or not my "laborers" are, in actuality,
professionals.

We continue. There are few "laborers" who fit the mold that Ted describes.
While there are many 9-5 programmers, and many others who write cut-paste code, and
still others who write big, ugly, bloated code, these aren't always the same people.
I know lots of 12-12 programmers who work hellish hours, and write bloated, ugly,
cut-paste code. I also know many 9-5 programmers who write clean and elegant code.
I know 9-5ers who don't give a rat's ass, and I know 9-5ers who care deeply. I know
12-12ers who's only care is to climb the corporate ladder, and others who work long
hours for the sheer joy of making something beautiful. Of course there
aren't, Bob, you took my description and sort of twisted it. (See above.) And yes,
I'll agree with you, there's lots of 9-5 developers, and lots of 12-12 developers,
lots of developers who write great code, and lots of developers who write crap code
and what's even funnier about this discussion is that sometimes they're all the same
person! (They do that just to defy this kind of stereotyping, I'm sure.) But maybe
it's just the companies I've worked for compared to the companies you've worked for,
but I can rattle off a vastly larger list of names who fit in the "9-5" category than
those who fit into the "12-12" category. All of them wanted to do a good job, I believe,
but I believe that because I believe that every human being innately wants to do things
they are proud of and can point to with a sense of accomplishment. Some will put more
energy into it than others. Some will have more talent for it than others. Just like
dancing. Or farming. Or painting. Or just about any endeavor.>
The Real Problem

Bob goes on to talk about the youth of our industry, but I think the problem is a
different one. Yes, we're a young industry, but frankly, so is Marketing and Sales
(they've only really existed in their modern forms for about sixty or seventy years,
maybe a hundred if you stretch the definitions a little), and ditto for medicine (remember,
it was only about 150 years ago that surgeons were also barbers). Yes, we have a LOT
to learn yet, and we're making a lot of mistakes, I think, because our youth is causing
us to reach out to other, highly imperfect metaphor/role-model industries for terminology
and inspiration. (Cue the discussion of "software architecture" vs "building architecture"
here.) Personally, I think we've learned a lot, we're continuing to learn more, and
we're reaching a point where looking at other industries for metaphors is reaching
a practical end in terms of utility to us.

The bigger problem? Economics. The supply and demand curve.

Neal Ford pointed out on an NFJS panel a few years back that the demand for software
vastly exceeds the supply of programmers to build it. I don't know where he got that--whether
he read that somewhere or that formed out of his own head--but he's absolutely spot-on
right, and it seriously throws the whole industry out of whack.

If the software labor market were like painting, or car repair, or accounting, then
the finite demand for people in those positions would mean that those who couldn't
meet customer satisfaction would eventually starve and die. Or, more likely, take
up some other career. It's a natural way to take the bottom 20% of the bell curve
(the portion out to the far right) of potential practitioners, and keep them from
ruining some customers' life. If you're a terrible painter, no customers will use
you (at least, not twice), and while I suppose you could pick up and move to a new
market every year or so until you're run out of town on a rail for crappy work, quite
honestly, most people will just give up and go do something else. There are thousands--millions--of
actors and actresses in Southern California that never make it to stage or screen,
and they wait tables until they find a new thing to pursue that adds value to their
customers' lives in such a way that they can make a living.

But software... right now, if you walk out into the middle of the street in San Francisco
wearing a T-shirt that says, "I write Rails code", you will have job offers flying
after you like the paper airplanes in Disney's
just-released-to-the-Internet video short [8]. IT departments are throwing huge amounts
of cash into mechanisms, human or otherwise, working or otherwise, to help them find
developers. Software
engineering has been at the top of the list of "best jobs" [9] for several years,
commanding high salaries in a relatively stress-free environment, all in a period
of time that many of equated to be the worst economic cycle since the Great Depression.
Don't believe me? Take a shot yourself, go to a Startup
Weekend [10] and sign up as a developer: there are hundreds of people with new app
ideas (granted, most of them total fantasy) who are just looking for a "technical
co-founder" to help them see their dream to reality. IT departments will take anybody right
now, and I do mean anybody. I'm reasonably convinced that half the reason software
development outsourcing overseas happens is because it's a choice between putting
up with doing the development overseas, even with all of the related problems and
obstacles that come up, or not doing the development at all for lack of being able
to staff the team to do it. (Which would you choose, if you were the CTO--some chance
of success, or no chance at all?)

Wrapping up

Bob wraps up with this: The result is that most programmers simply don't
know where the quality bar is. They don't know what disciplines they should adopt.
They don't know the difference between good and bad code. And, most importantly, they
have not learned that writing good clean code in a disciplined manner is the fastest
and best way get the job done well.

We, in the Software Craftsmanship movement are trying to teach those lessons. Our
goal is to raise the awareness that software quality matters. That doing a good job
means having pride in workmanship, being careful, deliberate, and disciplined. That
the best way to miss a deadline, and lay the seeds of defeat, is to make a mess.

We, in the Software Craftsmanship movement are promoting software professionalism. Frankly,
Bob, you sort of reject your own "we're not elitists" argument by making it very clear
here: "most programmers simply don't know where the quality bar is. They don't know
.... They don't know.... They have not learned. ... We, in the Software Craftsmanship
movement are trying to teach those lessons." You could not sound more elitist if you
quoted the colonial powers "bringing enlightenment" to the "uncivilized" world back
in the 1600s and 1700s. They are an ignorant, undisciplined lot, and you have taken
this self-appointed messiah role to bring them into the light.>

Seriously? You can't see how that comes across as elitist? And arrogant?

Look, I really don't mean to perpetuate this whole argument, and I'm reasonably sure
that Uncle Bob is already firing up his blog editor to point out all the ways in which
my "populist ideology" is falsly dichotomous or whatever. I'm tired of this argument,
to be honest, so let me try to sum up my thoughts on this whole mess in what I hope
will be a few, easy-to-digest bullet points:

1. Live craftsmanship, don't preach it. If you hold the craftsman meme as a way
   of trying to improve yourself, then you and I have no argument. If you put "software
   craftsman" on your business cards, or website, or write Manifestos that you try to
   use as a bludgeon in an argument, then it seems to me that you're trying to distinguish
   yourself from the rest, and that to me smacks of elitism. You may not think of yourself
   as covering yourself in elitism, but to a lot of the rest of the world, that's exactly
   how you're coming off. Sorry if that's not how you intended it.
2. Value is only value if the customer sees it as value. And the customer gets
   to define what is valuable to them, not you. You can (and should) certainly try to
   work with them to understand what they see as value, and you can (and should) certainly
   try to help them see how there may be value in ways they don't see today. But at the
   end of the day, they are the customer, they are paying the checks, and even after
   advising them against it, if they want to prioritize quick-and-dirty over longer-and-elegant,
   then (IMHO) that's what you do. Because they may have reasons for choosing that approach
   that they simply don't care to share with you, and it's their choice.
3. The creation of a label serves no purpose other than to disambiguate and distinguish. If
   there really is no blue-collar programming workforce, Bob, then I challenge you to
   drop the term "craftsman" from your bio, profile, and self-description anywhere it
   appears, and replace it with "programer". Or else refer to all software developers
   as "craftsmen" (in which case the term becomes meaningless, and thus useless). Because,
   let's face it, how many doctors do you know who put "Hippocratic-sworn" somewhere
   on their business cards?
4. If we want to hold people accountable to some sort of "professionalism", then we
   have to define what that means. The definition of the term "professional" is not
   really what we want, in practice, for it's usually defined as "somebody who got paid
   to do the job". The Craftsmanship Manifesto seems to want some kind of code of ethics
   or programmer equivalent to the Hippocratic Oath, so that the third precept isn't
   "a community of people who are paid to do what they do", but something deeper and
   more meaningful and concrete. (I don't have that definition handy, by the way, so
   don't look to me for it. But I will also roundly reject anyone who tries to use the
   Potter Stewart-esque "I can't define it but I know it when I see it" approach, because
   now we're back to individual interpretation.)
5. I found Uncle Bob's treatment of my blog heavy-handed and arrogant. In case
   that wasn't obvious. And I reacted in similar manner, something for which I will apologize
   now. By reacting in that way, I'm sure I perpetuate the blog war, and truthfully,
   I have a lot of respect for Bob's technical skills; I was an avid fan of his C++ articles
   for years, and there's a lot of good technical ideas and concepts that any programmer
   would be well-advised to learn. His technical skill is without question; his compassion
   and empathy, however, might be. (As are mine, for stooping to that same level.)

Peace out. >

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details [11].