The Dark Side of Software Craftsmanship

To get you in the mood, head on over to ElegantCode and take a look at this post.  It is highly likely that you agree with the sentiment of it, and that’s okay.  Generally speaking, you should (generally) agree with the sentiment.  I’ll wait.

Now that you’ve taken a look at it, if you’ve learned anything about ‘advanced’ software development (and here the software craftsmen will cringe that learning certain things should even be considered ‘advanced’ and they have a point), you’ll feel the pain of this:

One thing I have heard expressed in those places is, “software development is not our core competency, therefore recommendations around professional development practices don’t apply to us.”

And all of that is well and good.  But, the post goes on from that, and that’s where it goes terribly wrong.  Consider what follows:

“I don’t know where this absurd line of reasoning comes from, but I know why it is tolerated. It is tolerated because we don’t have the formal structures to hold professionals accountable the way we might hold an electrician, plumber, or physician accountable to being merely competent.”

No, no, and again, no.

To begin with, let’s ask a rhetorical question: have you ever met an incompetent plumber?  Exactly.  There’s nothing about ‘formal structures’ that guarantees, or even enables, competence. 

One only needs to look around at the bazillion certification processes, be they of the Microsoft variety or the Scrum variety or any other variety.  Have any of those solved the issue?  Nope.  Signing a craftsman manifesto won’t make anything better either.  Creating another formal structure won’t really get anywhere (well, it *might* have beneficial side effects, more on this in a minute) either.

It gets worse when you read this:

“We can hold ourselves accountable for professionalism no matter where we work.”

Here we get into danger territory.  “If you aren’t a software craftsman, you aren’t a professional.”  It isn’t stated explicitly here, but definitely implied.

No, no, and again, no.

This is very easily seen when you consider the list of things that (supposedly) imply or signify competence:

“In summary, no matter what type of organization you work for:

  • Yes, you need to use source control.
  • Yes, you need to automate the build.
  • No, you shouldn’t be releasing the assemblies compiled on your machine.
  • Yes, you need to stop writing long methods and pay attention to code complexity.
  • Yes, you need to buy your developers the best tools available.
  • No, you don’t need to write your own logging framework.
  • Yes, you should be practicing test first development.
  • No, continuing to ship known defects is not acceptable.
  • Yes, you should understand who your customer is.”


Let’s run through these.

“Yes, you need to use source control”

Okay, it’s hard to argue much about this one.  Let’s go with it.

“Yes, you need to automate the build.”

Maybe, maybe not.  Is automating the build something that will really provide a big benefit for the customer?  The frank answer is that it might not.  It *usually* will but it might not.  Especially when you consider:

“No, you shouldn’t be releasing the assemblies compiled on your machine.”

Again, it depends.  If you come across a situation where you are working to re-design an important system, it might be of almost no importance to do this.  If you are using source control in such a fashion where anyone with access to it can build successfully locally, deploying from your machine isn’t necessarily that important at all.  Given everything else, how important is this?

Yes, you need to stop writing long methods and pay attention to code complexity.”

As a general rule, it is hard to argue against this, depending on how you enforce it.  In an ideal world, working software with low code complexity is a good thing.  However, working software with high code complexity trumps unwritten and possibly non-working software with low code complexity.  How important is it, given everything else, to do this, especially if it involves re-writing working software?  You should begin to notice the importance of the phrase “given everything else.”

“Yes, you need to buy your developers the best tools available.”

Define ‘best.’  Given that your typical ‘advanced’ developers don’t often agree, for instance, on whether ReSharper is better or worse than CodeRush, it’s hard to say what is being advised here.  Real developers can develop using Notepad anyway (okay, I don’t actually believe that, but you’d be surprised at who might).

No, you don’t need to write your own logging framework. “ Okay, I’m going to whole-heartedly accept this one.  True story: working at a client where the ‘architect’ has decided to write their own logging framework, and not only to handle immediate needs, but to handle all possible future needs.  I ask him, “Have you heard of YAGNI?”  “What’s that?”  “You aren’t going to need it.”  “Yeah, I do that.”  “So, then you agree that we don’t need to design a custom framework to handle all possible future needs when you don’t know what those needs are, specifically.”  “No, that’s different.”  Right.  Have at it then.

“Yes, you should be practicing test first development.”

Notice the vagueness of ‘test first.’  If by this it means you should either be practicing TDD or some BDD-style thingy (disclaimer: I use SpecFlow as my first option every time I can), no, no, no, no, no and again, no. There are multitudes of software projects where the only testing you should be doing is integration testing, if even that.  This is especially true in my experience with ETL projects.  Obviously, you want to know that given a particular piece of data, if a transformation from the source to the destination is required, the transformation should be successful. Duh.  But in general, you should be testing the actual data, using statistical analysis.  Wasting your client’s time doing test-first development when it is inappropriate is wasting your client’s time. “

No, continuing to ship known defects is not acceptable.” It is perfectly acceptable if that is what your customer wants, which leads to the one thing I whole-heartedly accept above all else:

Yes, you should understand who your customer is.”

There’s a myth of software development in some circles that you cannot develop successful software unless you follow practice X or Y, where X might mean ‘agile’ or Y might mean ‘SOLID’, and this simply isn’t true, especially when ‘successful’ means ‘profitable.’ I have worked with clients that, for instance, profitably used software that used, forbid the thought, Access.  In the abstract, no one in their right mind would ever *recommend* this as a design.  But given a circumstance where such a system actually existed, thinking this is something that needs to be re-designed is almost as crazy. Millions and millions of dollars of revenue has been generated using, for instance, big balls of mud built on VB (not to pick on VB specifically, but…yeah, let’s pick on it).  Having worked with one of those ‘too big to fail’ financial institutions, close to billions of dollars of revenue were generated doing BDUF and all other sorts of things that I would not only not personally recommend as a starting point, but which I really didn’t enjoy.  But, close to billions of dollars of revenue were, in fact, generated.

David Starr is the author of the post in question, and a (the?) leader of “The Software Craftsman Cooperative.”  As a capitalist, I applaud the creation of this group (I’m pretty sure I’ve never met David, but I have met Jarod and Jason, and, for what it’s worth, I thought they were outstanding guys) and as a developer, I hope they are successful (in the hopes that there is a rising tide in chargeable rates). But, none of these people are qualified to tell me, or anyone else, what counts as professional software development. 

Yegge said it best:

“As far as I'm concerned, Agile Methodologies are fine for you to use, but if you try to push them on a coworker, it should be treated as an HR violation, just as if you were discriminating against them because they don't believe in Feng Shui.

If it's a manager pushing Agile on a subordinate, it should be treated with extra severity. Reprimand, goes on the employee record, mandatory training, and 3 strikes you're out.”

Replace “Agile” with “Craftsmanship” and you hopefully get the point. It could very well be beneficial to have the software HR hiring people to think “we should have some of that Craftsman stuff” when making hiring decisions, but it could also be very, very bad.

Later this week (or maybe next week), I will be deploying assemblies from my machine into production.  And I’m fine with that.  Anyone who (without knowing why as a professional I made that decision) wants to say I’m not a professional can bite me.

posted on Monday, August 09, 2010 10:23 PM Print
No comments posted yet.

Post Comment

Title *
Name *
Comment *  
Please add 5 and 4 and type the answer here: