Dan North has provided tremendous benefit to our profession and in the brief conversations I have had with him has proven to be an affable guy. I was a bit taken aback when I read his recent post: Programming is not a Craft. Dan?s sentiments are not unique. I have heard similar opinions from other prominent developers I respect.
I read in Dan’s post (and in some of the comments) a visceral reaction to gold plating things not determined "important" by the customer. I get that. I also see a need to temper this with the simple fact that the client doesn?t always know what is best for them. Let?s just get that out in the open. My doctor knows what is better for my physical body than I do and I am willing to pay for that. Will I always take the advice I am paying for? Well, probably not. And I?m sure that leaves my doctor shaking her head in dismay.
I learned that integrity is "doing the right thing even when no one is looking", and I see the Software Craftsmanship discussion as striving for integrity in the systems we create.
One mark of a true professional might be a willingness to balance client need with implementaion elegance resulting in software that meets the need of the client AND is something worthy of pride when shown to another developer. If the only reason we are writing code is to provide the minimum a client wants to pay for, then how compelling is my work, really? Can I be proud of my professional body of work if I am simply marching to orders? I say no.
Where I part ways with Dan is in his analogy of the plumber. Granted, I simply want my pipes to work, but I am willing to pay for a plumber that takes pride in his work. I trust that plumber will simply do a better job as he strives to make his work appreciated by the next plumber that sees it. Can I quantify this into dollars? Not really. Perhaps in the extra time required to lay in a perfectly soldered joint as opposed to a sloppy one. Am I willing to pay more for this type of person to do the work? No question: Yes.
The bottom line for me is that we would all like to take pride in our work. No one I?ve ever met gets up in the morning thinking, ?Today I will make a piece of crap?, and keeps at the job with any pleasure. We want to enjoy our work and be proud of it. Is that so bad? The very real software craftsmanship discussion simply gives us a vehicle for discussion in the pride we may take in our work for its own sake.
The risk to the craftsmanship community is to avoid getting carried away with dogma. Every time I hear Bob Martin assert to a 500 person room that if they aren’t writing unit tests they are "not professionals" or somehow unworthy of being in the room with him, I cringe. That?s a perfect way to draw fire and alienate people who might otherwise join you in your cause. It also happens to be a perfect way to stand out as a charismatic speaker who gets lots of attention, but I digress?
Do I write tests? Yes.
Always? No.
Am I ashamed when I don’t? Not really. Some jobs still call for duct tape.
Professionalism is knowing the appropriateness of a tool for a job and in always striving for integrity in our work.
My .02.
And, Dan, I admire and appreciate your contribution to our craft 
.
Good post, I have to agree.
Not too long ago I was on the strict dogma side of the fence, but lately I have realized there is a balance.
Writing good clean code and testing it is good, but it is not always right. It is extremely situational and I am starting to realize that now.
With the recent Android app I created, I started off creating unit tests and all these mocks and separating things into so many abstractions so each thing could be tested in isolation, but then I realized that I am the only developer working on the project, the size will be relatively small and I’ll never finish at this rate.
I ended up going the other way for a bit and just hacking bits and pieces together as I figured out what I needed to do, but then I saw how that was not the right approach either, as when I needed to make changes I felt the pain.
I finally ended up cleaning up everything, but not writing unit tests. Instead I focused on making clean maintainable logically consistent code with good clear defined roles. Now the codebase is wonderful to work in, is not overly burdensome and I can add features easily.
The point of my long story is that, I had to find the right balance that makes the most sense for this project. Sure Google Guice is pretty cool, but do I really need dependency injection in my Android app? Sure, it would be nice to write unit tests, but is it worth it to write them for a class that would require 5 mocks?
Having been the sole developer and person who was funding and standing to profit from the app, I learned an important principle. Bang for your buck!
This is exactly what I was thinking when I read Dans post. Great stuff.
Crazy talk!! You can’t of a view on something that isn’t in one extreme of the scale. That is just nuts.
Totally agree with you, David. Too bad we seem to be in minority (from my perspective, Bob Martin’s opinion is currently prevailing in the industry, at least for now).
That was very well said, and I completely agree!
Hi David. Thanks for taking the time to write this up, I appreciate your response.
It seems to me that we are agreeing. I want a plumber who takes a pride in his work, who bothers to learn and gain experience, who takes what he does seriously. I said as much in my post. I also want him to recognise that the output of his work is just plumbing to the rest of us, and as amazing as it might be, I just want hot water.
Of course I will expect to pay extra for that expertise, but it’s a wise investment compared to hiring a cowboy plumber and having to pay later to fix up the botch job he left me with:
Calling programming a trade takes nothing away from the desire for professionalism, experience and expertise. In the same way I want an expert electrician wiring up my house rather than a cowboy, I want an expert programmer enabling my business.
I never said I don’t want craftsmanship. I simply said programming isn’t a craft, it’s just a trade.
Do I write tests? Sometimes – it depends. Not as many as I used to, but better and more targetted (I think). I’ve learned a lot about tests, and I’m still learning.
Am I writing duct-tape code when I don’t? Not usually – just balancing the risk and cost of not testing with getting work done.
Thanks for your kind words,
Dan