On Twitter, Alfonso Guerra (@Huperniketes) asked me, “Okay, tell me how [software] quality will improve by prog[rammer]s taking more resp[onsibility] for quality?” My response is longer than 140 characters, so I’m replying here.

For background, my involvement in the conversation started when he caught my eye with

The problem with the Software Craftsmanship movement is its attempt to create a race of superprogrammers who can save [software] from bad [project management].

Well, I don’t know anyone promoting Software Craftsmanship who thinks that.To my reading, there are two threads in Alfonso’s logic.  One is that there are many important parts to software development that are not programming.  He mentions process, requirements, design, priorities.  Certainly if the business chooses the wrong thing to build, or insists on poor prioritization, the project can fail. And working with a poor process can also doom a team.

Again, it is possible to fail in many ways (for evil belongs to the class of the unlimited, as the Pythagoreans conjectured, and good to that of the limited)

— Aristotle, Nicomachean Ethics, Translated by W. D. Ross

Clearly it is not sufficient for success to have good engineering practices.  Bad management can always sink the ship.

Design is another matter.  It is part of programming–at least, programming done well. In fact, one of the greatest indicators of the need for Software Craftsmanship is programmers not considering design while they’re coding.  To consider design separate, and distinct, from programming will certainly lead to mediocre programming, and, in my observation, mediocre designs.

The wording of some of Alfonso’s tweets suggests to me that the second thread of logic is that there are a few brains, managers and perhaps software designers, who make the important decisions, and many hands to do their bidding.  He says, “The worker has limited [control] over his own effectiveness.” Instead, he posits that effectiveness is a function of process and process as the prerogative of management.  (Alfonso even sees simple techniques as TDD as something that must be approved by management in order to be practiced by programmers. They no more need to ask permission to practice TDD than ask whether they can use a Dvorak keyboard or a while loop.)

Such an attitude may have worked well for Henry Ford when he was churning out cars. I’ve never seen it work well for knowledge work. It sometimes give the appearance of necessity, though, when the attitude has chased off the craftmen and left the ignorant or subjugated to toil under whatever conditions are necessary to earn their living.  Such an attitude robs the programmers of the responsibility for their own work.

And it is taking responsibility for their own work that is the heart of Software Craftsmanship, not the heroics that Alfonso imagines.  It’s a quiet strength built of knowledge and practice that enables the developers to build excellent programs that are more robust in usage and enhancement.

Without solid craftsmanship, programs often have flaky bugs and behavior that differs depending on usage patterns. And I’ve never seen a manager lead a successful software project without programmers. Programming skill is yet one more requirement for success, and lack of it is one more way to fail.