Referring to The Manifesto for Software Craftsmanship, product development executive Charl Dreyer asks
Is another manifesto necessary?
The Manifesto for Software Craftsmanship offers up quality addenda to the Manifesto for Agile Software Development. Charl Dreyer wonders if this is necessary (see Dreyer’s Raising The Bar).
Robert Vitello, CIO at New York State Labor Department, says
Although well meant, the Manifesto for Software Craftsmanship seems too unspecific to have real value on the ground. When such pronouncements are too lofty or too general, they are subject to the kind of variable interpretation that cause the authors to rail against the original Manifesto.
I agree with Robert’s critique. There is not much mental traction served up by platitudes like steadily added value or productive partnerships.
Nonetheless I signed The Manifesto for Software Craftsmanship because I support the intent.
If quality is sufficiently defined, who would be anti-quality?
It is perhaps important to remember that
the quality of something does not necessarily determine its value
Something might be good because it is useful, because it is beautiful, or because it exists. I like the aesthetic appeal of sparse but powerful code -- one or two lines of code that does a lot - but I can't assert that it always provides economic value. Sometimes we favor elegance over expedience; not always providing demonstrable economic value. We are employed in the software business to increase economic value.
The craftsmanship addenda to the agile manifesto are born from noble purpose. Open-ended, nearly inscrutable bromides like “well-crafted software” are potentially helpful insomuch as they can promote collective examination and collective improvement. Yes, examination and improvement are good! Lofty, intellectually fuzzy declarations are potentially helpful insomuch as they promote thought about-, and discussion of-, elusive terms like “value” and “quality”.
I like the concept of a team-level “craftsmanship contract” during chartering. I took a swing at this topic a while back in my post Team Manifesto - Craftsmanship, Behavior & Minutiae. Creating a craftsmanship contract starts with the open-ended question
What does software quality mean to you?
The goal is to end up with testable assertions. That is, to end up with prominently displayed bullet points that are meaningful to the team and testable in retrospectives.
What constitutes software quality?
Is software quality a personal matter or is it a collective concern of the team? I would like to hear your thoughts.
I think it has to be both.
ReplyDeleteThe team needs to care about it because they are responsible, as a team, for the delivery of production quality results.
Individuals have to care about their quality or the team cannot achieve its overall goal.
The team can also contribute to raising each individual's quality.
Hi! You say 'We are employed in the software business to increase economic value.' I think this is a somewhat limited statement. Sure, when push comes to shove, money talks, and all that, but, as we're talking about quality, of the four criteria by which a a project can be measured (scope, cost, time, product quality), it's quality that will matter most to the customer, because the customer will quickly forget if he/she paid too much for something that came too late with too few features. But if the product is simply bad, then nothing can compensate for that.
ReplyDeleteCompromising quality for the sake of any of the other three is usually a step in the wrong direction.
You’re point is well-taken Stephen. Thanks for modifying my thinking. We shouldn't think our employment as software professionals simply in economic terms. While it might very well be a management mantra to” increase economic value”, the reality often is that if a software product turns out to be collectively received as a success (e.g., because it is new concept, or looks cool, or the marketing department has put a good spin on it, or customer reaction is positive), almost everyone is satisfied even if no one can point to resulting cost reductions or improved revenues.
ReplyDeleteScott - you make a good point. There's a team standard and a personal standard of quality. Both essential. To me, that's why it is important at the outset to define quality in specific terms (since everyone has a different take), then negotiate the standards that the team will strive to uphold.
ReplyDeleteI think Henrik Kniberg put it quite nicely when he said that software quality can be measured in two ways - "internal" and "external" quality. The former refers to the code itself - are modules decoupled from one another, is it easy to read, is it rigid or open to change etc. etc., whilst the latter is concerned with issues such as "does it respond to mouse clicks quickly" or "does it do what it's supposed to do" or "does it crash a lot" etc. etc.
ReplyDeleteThe upshot is that software with low internal quality rarely has high external quality (or if it does, it is often short lived). Conversely, software with a high internal quality has a better chance but will not necessarily have a high external quality e.g. requirements were wrong and the app doesn't do what the users expected.
I find that the Craftsmanship Manifesto does not stand upon its feet. It refers to the Agile Manifesto for context but doesn't give attribute or reference. For example: "Not only individuals and interactions, but also a community of professionals." Without the context of the Agile Manifesto what do they mean by "Not only individuals and interactions"?
ReplyDeleteSo taken as a work of art in literature, this work fails to stand up. It may be considered plagiarism. It lacks the craftsmanship of an editor.
But I do like what I *think* they mean - and what a nice background image. It feels good.
David – Shoddily crafted declarations about craftsmanship bring to mind the slogan “fight for world peace”. But, like you, I support the intention.
ReplyDeleteAbout the SC Manifesto, I have a feeling that it's preaching to the choir. My (albeit limited) observation is that people who "get" the Agile Manifesto already get what's in this new one. Those who don't, don't. As someone else has said elsewhere, this new manifesto is kind of implicit and has a "duh!" factor about it. No value add, in other words.
ReplyDeleteStephen - Could the value simply be a reminder to those of us who have gotten proficient in the "ceremony" of we run our projects (e.g., Scrum), and have perhaps started sleep-walking, to get back to examining the quality of our product? Perhaps examining the quality of what we produce beyond what meets minimum acceptance criteria?
ReplyDeleteIsaac - thanks to you and Henrik Kniberg for the important distinction between external and internal. I like the 3 quick items you listed as important internal attributes.
ReplyDelete