Arrogant, slow and dogmatic

What does it mean to be a software craftsman? You can read the Manifesto for Software Craftsmanship and draw conclusions; but if you posed that question to different people across the software industry, you’d hear any number of different responses. And to some degree, they’re all true. Descriptions are ultimately bound to perspective, and there appear to be divergent perspectives on the software craftsmanship movement. What follows are three descriptions that are commonly wielded against the software craftsmanship community, accompanied by an explanation of the craftsman’s perspective on the same issue.

~ Paul Pagel, from Software Craftsmen Are Arrogant, Slow, and Dogmatic

Craftsmanship

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value…

~ Manifesto for Software Craftsmanship

Over time, the ideal of craftsmanship was cordoned off to just the technical arts. Physicians and legislators no longer thought of themselves as craftsmen, but as philosophers and natural scientists who were more concerned with the theoretical as opposed to the practical. Such a shift is a shame, for the principles of craftsmanship truly do apply to every man, whether he makes furniture or crunches numbers.

~ Brett & Kate McKay, from Measure Twice, Cut Once.

Try to ask a doctor or any engineer to do a crappy job in order to reduce costs. Engineers can change product’s materials to cheaper ones, they can change product’s final characteristics, but they don’t change their level of attention and their process of doing things the way they think it’s right. Doctors can perform simpler or different procedures by patient request, impacting somehow on the final result, but the attention, caring and cleanliness will be the same.

~ Caio Fernando Bertoldi Paes de Andrade, from a message to the Software Craftsmanship group

Keep it simple. Good luck with that.

good_luckIn fact it is so difficult to argue against simplicity that this post won’t even attempt to.  Let’s state emphatically that software should always do only what you need it to do, with the fewest number of steps, and least potential for errors due to complex choices and options.

On the other hand, good luck with that.

~ Steven Sinofsky from Designing for scale and the tyranny of choice