Carlo Kruger commented on my last blog post with reference to Martin Fowler’s blog post which is a concise view of a crazy blog and twitter war around software craftmanship.  For some reason, Carlo thinks that my last two blog posts (here and here) fall into this space. Either Carlo is baiting a hook for fun 😉 or he misunderstood me. Nevertheless, my dear friend, I shall reply.
Martin Fowler and Dan North put the customer’s derived value from the software as the focal point.  The craftmanship movement puts the code that derives the value as the focal point.  I don’t feel comfortable about either.  It is unbalanced.  We always need balance.  So, what will provide an equally powerful balancing force to either of these two focal points?  I think it is the economic viability of the code base.

In Let scrum die, the key message is that Scrum should not be the end goal but a means to get somewhere better.  At some point it will outlive it’s value and I propose a moment in time when that will happen, and one way to force this (i.e. plan the exit of the Scrum master).  I also describe “talented developers” which, perhaps, feels like a craftmanship-esque thing.  It’s not about that at all.  It’s about the balance that is described in the next to last paragraph: developers will represent the interest of the customer, and the code base is under control (i.e. it is economically viable).  Balance the focus of methodology with an the economic viability of the code base.

In You can’t let Scrum die, I draw attention to this lack of balance that leads to complacency.  I mention two craftmanship things to do with the code – remove duplication and express intentions.  Again, it’s not about this alone.  It’s about the balance that is needed.  That balance is described in the next to last paragraph: look at yourself and look at what you create (i.e. the code base).  The reason why I say look at the person next to you is because the economic viability of the code that you create will affect that other person also, including the entire organisation and its customers.  Balance the craftmanship with the methodology which is balanced by the economic viability of the code base.  This reduces to balancing craftmanship with the economic viability of the code base.

There is one area where I don’t know of a powerful enough balancing force.  In Politics of Software Delivery, I draw attention to organisational power grabbing that will always result in non-delivery.  I suggest raising the importance of the delivery value.  But I think this is still too weak a force to balance the power battle.  I don’t know how to fix that one.

Footnote: Jimmy Nilsson reminded me of an article he wrote about why TDD, Refactoring, DDD, and all such things matter.