In another consensus building effort, I've tried to gather up all the
principles that have been batted around lately.
Where possible, I've indicated the origin of the principle to the best
of my knowledge. I've pulled many directly out of McBreen's book.
Some of those we haven't really discussed yet. Those credited to
UncleBob are from his "Craftsmanship and Ethics" talk. Other credits
are from list activity.
Feel free to add to the page, but please don't delete (yet).
The Craftsman
We follow our chosen practices deliberately, to ensure quality in our
work" (Summit / BenRady)
We adopt development processes to suit our own unique abilities and
talents (McBreen, 35)
We are skill-centric rather than process-centric. (Ade)
We are generalists (McBreen, 21)
We achieve technical and design excellence through continuous and
deliberate learning and practice. (Enrique)
We build our reputations on delivered quality (McBreen, 37)
We desire to remain Software Craftsmen and write code for our entire
careers(McBreen, 73)
We respect master craftsmen as the key to Software Craftsmanship
(McBreen, 85)
The Craftsman's Product (well-crafted software)
We write code that is easy to read, understand and modify.(Summit)
We believe the code is also an end, not just a means.(Summit)
We treat software like capital (McBreen, 155)
We build in quality to the software we create. (McBreen, 41)
We sign our work (McBreen, 52)
We put predicable and forgiving user interfaces on our software
(McBreen, 163)
We design software for testing and maintenance (McBreen, 155, 165)
We value long lived technologies and languages and are wary of
proprietary tools (McBreen, 87)
We drive our development with tests (UncleBob)
The Craftsman's Rhythm (steadily adding value)
We say no to prevent doing harm to our craft and our projects
(Summit)
We keep projects from spinning in circles(Doug)
We value quality over feature set of delivery data (McBreen, 64)
We build long-lived application and support them throughout their
life (McBreen, 65, 80)
We deliver what our customers really need, not just what they ask for
(McBreen, 83)
We automate every task possible (especially testing) (McBreen, 63)
We don't wait for complete definition before beginning (UncleBob)
We never allow ourselves to be blocked (UncleBob)
The Craftsman's Community (a community of professionals)
We work in a community with other craftsmen (Summit)
Our livelihoods and reputations are interdependent (Doug)
We will help other craftsmen in their journey (Summit)
We can point to the people who influenced us and who we influenced
(Summit)
We take on Apprentices and put them in an environment where they can
learn our craft for themselves (McBreen, 97)
We recommend other craftsmen, hanging our own reputation on their
performance. (McBreen, 38)
We accept that different craftsmen are better suited for one kind of
job over another (Jim Highsmith via McBreen, 65)
The Craftsman's Customer (productive partnerships)
We are proud of our work and the manner of our work (Summit)
We take responsibility for the code we write (Summit)
We are proud of our portfolio of successful projects (Summit)
We take our customer's needs as seriously as they do (UncleBob)
We build Trust and respect with our customers (McBreen, 54)
We build long term relationships with customers (McBreen, 65)
We desire demanding users (McBreen, 147)
We consistently exceed and raise our customer's expectations of
quality software (Hoover)
The one thing that jumps out at me immediately, given Jason's recent
comments about not making "Software Craftsmanship = XP done properly" is:
"We drive our development with tests (UncleBob)"
Now, don't get me wrong; I'm an advocate and practitioner of TDD, however,
could we be a bit more inclusive with something like:
"We validate and improve the skills, processes and product of our craft with
tests"
Maybe not as snappy as UncleBob's; hopefully you get the idea... This
principle does not /prescribe/ TDD, or any other approach, but acknowledges
the value of validating what we do in order to improve it.
On Thu, Mar 12, 2009 at 11:40 AM, Doug <d...@8thlight.com> wrote:
> Craftsmen,
> In another consensus building effort, I've tried to gather up all the
> principles that have been batted around lately.
> Where possible, I've indicated the origin of the principle to the best
> of my knowledge. I've pulled many directly out of McBreen's book.
> Some of those we haven't really discussed yet. Those credited to
> UncleBob are from his "Craftsmanship and Ethics" talk. Other credits
> are from list activity.
> Feel free to add to the page, but please don't delete (yet).
> The Craftsman
> We follow our chosen practices deliberately, to ensure quality in
> our
> work" (Summit / BenRady)
> We adopt development processes to suit our own unique abilities and
> talents (McBreen, 35)
> We are skill-centric rather than process-centric. (Ade)
> We are generalists (McBreen, 21)
> We achieve technical and design excellence through continuous and
> deliberate learning and practice. (Enrique)
> We build our reputations on delivered quality (McBreen, 37)
> We desire to remain Software Craftsmen and write code for our entire
> careers(McBreen, 73)
> We respect master craftsmen as the key to Software Craftsmanship
> (McBreen, 85)
> The Craftsman's Product (well-crafted software)
> We write code that is easy to read, understand and modify.(Summit)
> We believe the code is also an end, not just a means.(Summit)
> We treat software like capital (McBreen, 155)
> We build in quality to the software we create. (McBreen, 41)
> We sign our work (McBreen, 52)
> We put predicable and forgiving user interfaces on our software
> (McBreen, 163)
> We design software for testing and maintenance (McBreen, 155, 165)
> We value long lived technologies and languages and are wary of
> proprietary tools (McBreen, 87)
> We drive our development with tests (UncleBob)
> The Craftsman's Rhythm (steadily adding value)
> We say no to prevent doing harm to our craft and our projects
> (Summit)
> We keep projects from spinning in circles(Doug)
> We value quality over feature set of delivery data (McBreen, 64)
> We build long-lived application and support them throughout their
> life (McBreen, 65, 80)
> We deliver what our customers really need, not just what they ask
> for
> (McBreen, 83)
> We automate every task possible (especially testing) (McBreen, 63)
> We don't wait for complete definition before beginning (UncleBob)
> We never allow ourselves to be blocked (UncleBob)
> The Craftsman's Community (a community of professionals)
> We work in a community with other craftsmen (Summit)
> Our livelihoods and reputations are interdependent (Doug)
> We will help other craftsmen in their journey (Summit)
> We can point to the people who influenced us and who we influenced
> (Summit)
> We take on Apprentices and put them in an environment where they can
> learn our craft for themselves (McBreen, 97)
> We recommend other craftsmen, hanging our own reputation on their
> performance. (McBreen, 38)
> We accept that different craftsmen are better suited for one kind of
> job over another (Jim Highsmith via McBreen, 65)
> The Craftsman's Customer (productive partnerships)
> We are proud of our work and the manner of our work (Summit)
> We take responsibility for the code we write (Summit)
> We are proud of our portfolio of successful projects (Summit)
> We take our customer's needs as seriously as they do (UncleBob)
> We build Trust and respect with our customers (McBreen, 54)
> We build long term relationships with customers (McBreen, 65)
> We desire demanding users (McBreen, 147)
> We consistently exceed and raise our customer's expectations of
> quality software (Hoover)
> In another consensus building effort, I've tried to gather up all the
> principles that have been batted around lately.
> Where possible, I've indicated the origin of the principle to the best
> of my knowledge. I've pulled many directly out of McBreen's book.
> Some of those we haven't really discussed yet. Those credited to
> UncleBob are from his "Craftsmanship and Ethics" talk. Other credits
> are from list activity.
> Feel free to add to the page, but please don't delete (yet).
> The Craftsman
> We follow our chosen practices deliberately, to ensure quality in our
> work" (Summit / BenRady)
> We adopt development processes to suit our own unique abilities and
> talents (McBreen, 35)
> We are skill-centric rather than process-centric. (Ade)
> We are generalists (McBreen, 21)
> We achieve technical and design excellence through continuous and
> deliberate learning and practice. (Enrique)
> We build our reputations on delivered quality (McBreen, 37)
> We desire to remain Software Craftsmen and write code for our entire
> careers(McBreen, 73)
> We respect master craftsmen as the key to Software Craftsmanship
> (McBreen, 85)
> The Craftsman's Product (well-crafted software)
> We write code that is easy to read, understand and modify.(Summit)
> We believe the code is also an end, not just a means.(Summit)
> We treat software like capital (McBreen, 155)
> We build in quality to the software we create. (McBreen, 41)
> We sign our work (McBreen, 52)
> We put predicable and forgiving user interfaces on our software
> (McBreen, 163)
> We design software for testing and maintenance (McBreen, 155, 165)
> We value long lived technologies and languages and are wary of
> proprietary tools (McBreen, 87)
> We drive our development with tests (UncleBob)
> The Craftsman's Rhythm (steadily adding value)
> We say no to prevent doing harm to our craft and our projects
> (Summit)
> We keep projects from spinning in circles(Doug)
> We value quality over feature set of delivery data (McBreen, 64)
> We build long-lived application and support them throughout their
> life (McBreen, 65, 80)
> We deliver what our customers really need, not just what they ask for
> (McBreen, 83)
> We automate every task possible (especially testing) (McBreen, 63)
> We don't wait for complete definition before beginning (UncleBob)
> We never allow ourselves to be blocked (UncleBob)
> The Craftsman's Community (a community of professionals)
> We work in a community with other craftsmen (Summit)
> Our livelihoods and reputations are interdependent (Doug)
> We will help other craftsmen in their journey (Summit)
> We can point to the people who influenced us and who we influenced
> (Summit)
> We take on Apprentices and put them in an environment where they can
> learn our craft for themselves (McBreen, 97)
> We recommend other craftsmen, hanging our own reputation on their
> performance. (McBreen, 38)
> We accept that different craftsmen are better suited for one kind of
> job over another (Jim Highsmith via McBreen, 65)
> The Craftsman's Customer (productive partnerships)
> We are proud of our work and the manner of our work (Summit)
> We take responsibility for the code we write (Summit)
> We are proud of our portfolio of successful projects (Summit)
> We take our customer's needs as seriously as they do (UncleBob)
> We build Trust and respect with our customers (McBreen, 54)
> We build long term relationships with customers (McBreen, 65)
> We desire demanding users (McBreen, 147)
> We consistently exceed and raise our customer's expectations of
> quality software (Hoover)
> In another consensus building effort, I've tried to gather up all the
> principles that have been batted around lately.
> Where possible, I've indicated the origin of the principle to the best
> of my knowledge. I've pulled many directly out of McBreen's book.
> Some of those we haven't really discussed yet. Those credited to
> UncleBob are from his "Craftsmanship and Ethics" talk. Other credits
> are from list activity.
> Feel free to add to the page, but please don't delete (yet).
> The Craftsman
> We follow our chosen practices deliberately, to ensure quality in our
> work" (Summit / BenRady)
> We adopt development processes to suit our own unique abilities and
> talents (McBreen, 35)
> We are skill-centric rather than process-centric. (Ade)
> We are generalists (McBreen, 21)
> We achieve technical and design excellence through continuous and
> deliberate learning and practice. (Enrique)
> We build our reputations on delivered quality (McBreen, 37)
> We desire to remain Software Craftsmen and write code for our entire
> careers(McBreen, 73)
> We respect master craftsmen as the key to Software Craftsmanship
> (McBreen, 85)
> The Craftsman's Product (well-crafted software)
> We write code that is easy to read, understand and modify.(Summit)
> We believe the code is also an end, not just a means.(Summit)
> We treat software like capital (McBreen, 155)
> We build in quality to the software we create. (McBreen, 41)
> We sign our work (McBreen, 52)
> We put predicable and forgiving user interfaces on our software
> (McBreen, 163)
> We design software for testing and maintenance (McBreen, 155, 165)
> We value long lived technologies and languages and are wary of
> proprietary tools (McBreen, 87)
> We drive our development with tests (UncleBob)
> The Craftsman's Rhythm (steadily adding value)
> We say no to prevent doing harm to our craft and our projects
> (Summit)
> We keep projects from spinning in circles(Doug)
> We value quality over feature set of delivery data (McBreen, 64)
> We build long-lived application and support them throughout their
> life (McBreen, 65, 80)
> We deliver what our customers really need, not just what they ask for
> (McBreen, 83)
> We automate every task possible (especially testing) (McBreen, 63)
> We don't wait for complete definition before beginning (UncleBob)
> We never allow ourselves to be blocked (UncleBob)
> The Craftsman's Community (a community of professionals)
> We work in a community with other craftsmen (Summit)
> Our livelihoods and reputations are interdependent (Doug)
> We will help other craftsmen in their journey (Summit)
> We can point to the people who influenced us and who we influenced
> (Summit)
> We take on Apprentices and put them in an environment where they can
> learn our craft for themselves (McBreen, 97)
> We recommend other craftsmen, hanging our own reputation on their
> performance. (McBreen, 38)
> We accept that different craftsmen are better suited for one kind of
> job over another (Jim Highsmith via McBreen, 65)
> The Craftsman's Customer (productive partnerships)
> We are proud of our work and the manner of our work (Summit)
> We take responsibility for the code we write (Summit)
> We are proud of our portfolio of successful projects (Summit)
> We take our customer's needs as seriously as they do (UncleBob)
> We build Trust and respect with our customers (McBreen, 54)
> We build long term relationships with customers (McBreen, 65)
> We desire demanding users (McBreen, 147)
> We consistently exceed and raise our customer's expectations of
> quality software (Hoover)
I don't think this list of principles is either specific enough or general enough to satisfy everyone on this list, let alone everyone who signed the manifesto. It's far more than the simplest thing that can possibly work (STtcPW).
I don't think that Doug is proposing we use this list. This list is a starting point, a superset that we can whittle down and adapt to exactly what we want.
On Wed, Mar 11, 2009 at 9:59 PM, Denny Abraham <de...@8thlight.com> wrote:
> I don't think this list of principles is either specific enough or > general enough to satisfy everyone on this list, let alone everyone > who signed the manifesto. It's far more than the simplest thing that > can possibly work (STtcPW).
> I don't think that Doug is proposing we use this list. This list is a
> starting point, a superset that we can whittle down and adapt to
> exactly what we want.
> Thanks for putting it together Doug!
> On Wed, Mar 11, 2009 at 9:59 PM, Denny Abraham <de...@8thlight.com>
> wrote:
>> I don't think this list of principles is either specific enough or
>> general enough to satisfy everyone on this list, let alone everyone
>> who signed the manifesto. It's far more than the simplest thing that
>> can possibly work (STtcPW).
On Wed, Mar 11, 2009 at 8:04 PM, Jason Gorman <goo...@parlezuml.com> wrote:
> Oh well. So much for the broader church and taking a step back :-)
> On Mar 12, 12:40 am, Doug <d...@8thlight.com> wrote: >> Craftsmen,
>> In another consensus building effort, I've tried to gather up all the >> principles that have been batted around lately.
>> Where possible, I've indicated the origin of the principle to the best >> of my knowledge. I've pulled many directly out of McBreen's book. >> Some of those we haven't really discussed yet. Those credited to >> UncleBob are from his "Craftsmanship and Ethics" talk. Other credits >> are from list activity.
>> Feel free to add to the page, but please don't delete (yet).
>> The Craftsman >> We follow our chosen practices deliberately, to ensure quality in our >> work" (Summit / BenRady) >> We adopt development processes to suit our own unique abilities and >> talents (McBreen, 35) >> We are skill-centric rather than process-centric. (Ade) >> We are generalists (McBreen, 21) >> We achieve technical and design excellence through continuous and >> deliberate learning and practice. (Enrique) >> We build our reputations on delivered quality (McBreen, 37) >> We desire to remain Software Craftsmen and write code for our entire >> careers(McBreen, 73) >> We respect master craftsmen as the key to Software Craftsmanship >> (McBreen, 85)
>> The Craftsman's Product (well-crafted software) >> We write code that is easy to read, understand and modify.(Summit) >> We believe the code is also an end, not just a means.(Summit) >> We treat software like capital (McBreen, 155) >> We build in quality to the software we create. (McBreen, 41) >> We sign our work (McBreen, 52) >> We put predicable and forgiving user interfaces on our software >> (McBreen, 163) >> We design software for testing and maintenance (McBreen, 155, 165) >> We value long lived technologies and languages and are wary of >> proprietary tools (McBreen, 87) >> We drive our development with tests (UncleBob)
>> The Craftsman's Rhythm (steadily adding value) >> We say no to prevent doing harm to our craft and our projects >> (Summit) >> We keep projects from spinning in circles(Doug) >> We value quality over feature set of delivery data (McBreen, 64) >> We build long-lived application and support them throughout their >> life (McBreen, 65, 80) >> We deliver what our customers really need, not just what they ask for >> (McBreen, 83) >> We automate every task possible (especially testing) (McBreen, 63) >> We don't wait for complete definition before beginning (UncleBob) >> We never allow ourselves to be blocked (UncleBob)
>> The Craftsman's Community (a community of professionals) >> We work in a community with other craftsmen (Summit) >> Our livelihoods and reputations are interdependent (Doug) >> We will help other craftsmen in their journey (Summit) >> We can point to the people who influenced us and who we influenced >> (Summit) >> We take on Apprentices and put them in an environment where they can >> learn our craft for themselves (McBreen, 97) >> We recommend other craftsmen, hanging our own reputation on their >> performance. (McBreen, 38) >> We accept that different craftsmen are better suited for one kind of >> job over another (Jim Highsmith via McBreen, 65)
>> The Craftsman's Customer (productive partnerships) >> We are proud of our work and the manner of our work (Summit) >> We take responsibility for the code we write (Summit) >> We are proud of our portfolio of successful projects (Summit) >> We take our customer's needs as seriously as they do (UncleBob) >> We build Trust and respect with our customers (McBreen, 54) >> We build long term relationships with customers (McBreen, 65) >> We desire demanding users (McBreen, 147) >> We consistently exceed and raise our customer's expectations of >> quality software (Hoover)
Thanks for doing this Doug.
Below I've pasted a section from the introduction to Apprenticeship
Patterns where we (Dave Hoover and myself0 try to describe what we see
as the heart of software craftsmanship:
====
One of the lessons we've learned from the Agile movement is that just
telling people to do things doesn't actually cause lasting or
sustainable change. When they get to a situation that isn't covered by
the rules they're lost. However if those people have imbibed the
values that underpin the rules then they can come up with new rules to
fit any situation. Our goal here is not to hand people a rule book but
to give them the ability to create new practices for new contexts that
can drive the discipline of software development forwards.
Our vision of software craftsmanship is partly a distillation of the
values of the highly skilled individuals we've interviewed and partly
an expression of the kind of community we would like to see emerge.
The ideas in this book are a starting point not an ending for that
vision. So when we use the phrase software craftsmanship we're talking
about a community of practice united and defined by overlapping values
including:
- An attachment to Carol Dweck's research (Mindset and Self-theories)
which calls for a "growth mindset." This entails a belief that you can
always be better and everything can always be improved if you're
prepared to work at it. In her words "effort is what makes makes you
smart or talented" Mindset (page 16) and failure is merely an
incentive to try a different approach next time. It is the opposite of
the belief that we're all born with a given amount of talent and
failure is just an indication that you don't have enough talent.
- A need to always be adapting and changing based on the feedback you
get from the world around you. Gawande refers to this as a willingness
to "recognize the inadequacies in what you do and to seek out
solutions" Better (page 257).
- A desire to be pragmatic rather than dogmatic. This involves a
willingness to trade-off getting things done today against theoretical
purity or future perfection.
- A belief that it is better to share what we know than to create
scarcity by hoarding it. This is connected to an involvement in the
Free and Open Source Software communities.
- A willingness to experiment and be proven wrong. This means we try
stuff. We fail. Then we use the lessons from that failure in the next
experiment. As Virginia Postrel puts it "not every experiment or idea
is a good one, but only by trying new ideas do we discover genuine
improvements. And there is always more to be done. Every improvement
can be improved still further; every new ideas makes still more new
combinations possible" The Future and its Enemies (page 59).
- A dedication to what psychologists call an internal locus of
control. This involves taking control of and responsibility for our
destinies rather than just waiting for someone else to give us the
answers.
- A focus on individuals rather than groups. This is not a movement
with leaders and followers. Instead we are a group of people who want
to improve our skills and have discovered that debate, dissent and
disagreement rather than blind deference to self-proclaimed authority
are the way to get there. We believe we are all on the same journey
and the change we seek is in ourselves not the world. This is why this
book doesn't focus on how to fix your team but just on ways to improve
your own skills.
- A commitment to inclusiveness. We don't reject enterprise software
development, or computer science or software engineering (in fact Ade
has the word "Engineer" in his current job title). Instead we think
that a useful system should be able to identify and absorb the best
ideas from all elements of the software development community.
- We are skill-centric rather than process-centric. For us it is more
important to be highly skilled than to be using the 'right' process.
This has consequences. Gawande asked "Is medicine a craft or an
industry? If medicine is a craft, then you focus on teaching
obstetricians to acquire a set of artisanal skills[...] You do
research to find new techniques. You accept that things will not
always work out in everyone's hands Better (page 192). It suggests
that no process or tool is going to make us all equally successful.
Even though we can all improve there will always be discrepancies in
our skill levels.
- A strong preference for what Etiene Wenger calls "situated
learning". This is an idea which the software community has tried to
capture with patterns like Expert In Earshot. Its essence is that the
best way to learn is to be in the same room as a group of people who
are trying to achieve some goal using the skills you wish to learn.
====
> In another consensus building effort, I've tried to gather up all the
> principles that have been batted around lately.
> Where possible, I've indicated the origin of the principle to the best
> of my knowledge. I've pulled many directly out of McBreen's book.
> Some of those we haven't really discussed yet. Those credited to
> UncleBob are from his "Craftsmanship and Ethics" talk. Other credits
> are from list activity.
> Feel free to add to the page, but please don't delete (yet).
> The Craftsman
> We follow our chosen practices deliberately, to ensure quality in our
> work" (Summit / BenRady)
> We adopt development processes to suit our own unique abilities and
> talents (McBreen, 35)
> We are skill-centric rather than process-centric. (Ade)
> We are generalists (McBreen, 21)
> We achieve technical and design excellence through continuous and
> deliberate learning and practice. (Enrique)
> We build our reputations on delivered quality (McBreen, 37)
> We desire to remain Software Craftsmen and write code for our entire
> careers(McBreen, 73)
> We respect master craftsmen as the key to Software Craftsmanship
> (McBreen, 85)
> The Craftsman's Product (well-crafted software)
> We write code that is easy to read, understand and modify.(Summit)
> We believe the code is also an end, not just a means.(Summit)
> We treat software like capital (McBreen, 155)
> We build in quality to the software we create. (McBreen, 41)
> We sign our work (McBreen, 52)
> We put predicable and forgiving user interfaces on our software
> (McBreen, 163)
> We design software for testing and maintenance (McBreen, 155, 165)
> We value long lived technologies and languages and are wary of
> proprietary tools (McBreen, 87)
> We drive our development with tests (UncleBob)
> The Craftsman's Rhythm (steadily adding value)
> We say no to prevent doing harm to our craft and our projects
> (Summit)
> We keep projects from spinning in circles(Doug)
> We value quality over feature set of delivery data (McBreen, 64)
> We build long-lived application and support them throughout their
> life (McBreen, 65, 80)
> We deliver what our customers really need, not just what they ask for
> (McBreen, 83)
> We automate every task possible (especially testing) (McBreen, 63)
> We don't wait for complete definition before beginning (UncleBob)
> We never allow ourselves to be blocked (UncleBob)
> The Craftsman's Community (a community of professionals)
> We work in a community with other craftsmen (Summit)
> Our livelihoods and reputations are interdependent (Doug)
> We will help other craftsmen in their journey (Summit)
> We can point to the people who influenced us and who we influenced
> (Summit)
> We take on Apprentices and put them in an environment where they can
> learn our craft for themselves (McBreen, 97)
> We recommend other craftsmen, hanging our own reputation on their
> performance. (McBreen, 38)
> We accept that different craftsmen are better suited for one kind of
> job over another (Jim Highsmith via McBreen, 65)
> The Craftsman's Customer (productive partnerships)
> We are proud of our work and the manner of our work (Summit)
> We take responsibility for the code we write (Summit)
> We are proud of our portfolio of successful projects (Summit)
> We take our customer's needs as seriously as they do (UncleBob)
> We build Trust and respect with our customers (McBreen, 54)
> We build long term relationships with customers (McBreen, 65)
> We desire demanding users (McBreen, 147)
> We consistently exceed and raise our customer's expectations of
> quality software (Hoover)
I would start by removing the following principles...
"We drive our development with tests" (UncleBob) I could be persuaded (by Uncle Bob) to change my mind on this, but I don't see how this relates to Craftsmanship. It feels too low-level.
"We keep projects from spinning in circles" (Doug) This really doesn't tell anyone anything. No approach could disagree with this and therefore I don't think it's carrying its own weight.
"We don't wait for complete definition before beginning" (UncleBob) "We never allow ourselves to be blocked" (UncleBob) Again, these feel too low-level. I'd prefer that we not redefine XP as Software Craftsmanship.
There are others that I'd want to refine and reword. But I'll start with the above.
On Wed, Mar 11, 2009 at 7:40 PM, Doug <d...@8thlight.com> wrote:
> Craftsmen,
> In another consensus building effort, I've tried to gather up all the > principles that have been batted around lately.
> Where possible, I've indicated the origin of the principle to the best > of my knowledge. I've pulled many directly out of McBreen's book. > Some of those we haven't really discussed yet. Those credited to > UncleBob are from his "Craftsmanship and Ethics" talk. Other credits > are from list activity.
> Feel free to add to the page, but please don't delete (yet).
> The Craftsman > We follow our chosen practices deliberately, to ensure quality in our > work" (Summit / BenRady) > We adopt development processes to suit our own unique abilities and > talents (McBreen, 35) > We are skill-centric rather than process-centric. (Ade) > We are generalists (McBreen, 21) > We achieve technical and design excellence through continuous and > deliberate learning and practice. (Enrique) > We build our reputations on delivered quality (McBreen, 37) > We desire to remain Software Craftsmen and write code for our entire > careers(McBreen, 73) > We respect master craftsmen as the key to Software Craftsmanship > (McBreen, 85)
> The Craftsman's Product (well-crafted software) > We write code that is easy to read, understand and modify.(Summit) > We believe the code is also an end, not just a means.(Summit) > We treat software like capital (McBreen, 155) > We build in quality to the software we create. (McBreen, 41) > We sign our work (McBreen, 52) > We put predicable and forgiving user interfaces on our software > (McBreen, 163) > We design software for testing and maintenance (McBreen, 155, 165) > We value long lived technologies and languages and are wary of > proprietary tools (McBreen, 87) > We drive our development with tests (UncleBob)
> The Craftsman's Rhythm (steadily adding value) > We say no to prevent doing harm to our craft and our projects > (Summit) > We keep projects from spinning in circles(Doug) > We value quality over feature set of delivery data (McBreen, 64) > We build long-lived application and support them throughout their > life (McBreen, 65, 80) > We deliver what our customers really need, not just what they ask for > (McBreen, 83) > We automate every task possible (especially testing) (McBreen, 63) > We don't wait for complete definition before beginning (UncleBob) > We never allow ourselves to be blocked (UncleBob)
> The Craftsman's Community (a community of professionals) > We work in a community with other craftsmen (Summit) > Our livelihoods and reputations are interdependent (Doug) > We will help other craftsmen in their journey (Summit) > We can point to the people who influenced us and who we influenced > (Summit) > We take on Apprentices and put them in an environment where they can > learn our craft for themselves (McBreen, 97) > We recommend other craftsmen, hanging our own reputation on their > performance. (McBreen, 38) > We accept that different craftsmen are better suited for one kind of > job over another (Jim Highsmith via McBreen, 65)
> The Craftsman's Customer (productive partnerships) > We are proud of our work and the manner of our work (Summit) > We take responsibility for the code we write (Summit) > We are proud of our portfolio of successful projects (Summit) > We take our customer's needs as seriously as they do (UncleBob) > We build Trust and respect with our customers (McBreen, 54) > We build long term relationships with customers (McBreen, 65) > We desire demanding users (McBreen, 147) > We consistently exceed and raise our customer's expectations of > quality software (Hoover)
I would start by removing the following principles...
"We drive our development with tests" (UncleBob) I could be persuaded (by Uncle Bob) to change my mind on this, but I don't see how this relates to Craftsmanship. It feels too low-level.
"We keep projects from spinning in circles" (Doug) This really doesn't tell anyone anything. No approach could disagree with this and therefore I don't think it's carrying its own weight.
"We don't wait for complete definition before beginning" (UncleBob) "We never allow ourselves to be blocked" (UncleBob) Again, these feel too low-level. I'd prefer that we not redefine XP as Software Craftsmanship.
There are others that I'd want to refine and reword. But I'll start with the above.
On Wed, Mar 11, 2009 at 7:40 PM, Doug <d...@8thlight.com> wrote:
> Craftsmen,
> In another consensus building effort, I've tried to gather up all the > principles that have been batted around lately.
> Where possible, I've indicated the origin of the principle to the best > of my knowledge. I've pulled many directly out of McBreen's book. > Some of those we haven't really discussed yet. Those credited to > UncleBob are from his "Craftsmanship and Ethics" talk. Other credits > are from list activity.
> Feel free to add to the page, but please don't delete (yet).
> The Craftsman > We follow our chosen practices deliberately, to ensure quality in our > work" (Summit / BenRady) > We adopt development processes to suit our own unique abilities and > talents (McBreen, 35) > We are skill-centric rather than process-centric. (Ade) > We are generalists (McBreen, 21) > We achieve technical and design excellence through continuous and > deliberate learning and practice. (Enrique) > We build our reputations on delivered quality (McBreen, 37) > We desire to remain Software Craftsmen and write code for our entire > careers(McBreen, 73) > We respect master craftsmen as the key to Software Craftsmanship > (McBreen, 85)
> The Craftsman's Product (well-crafted software) > We write code that is easy to read, understand and modify.(Summit) > We believe the code is also an end, not just a means.(Summit) > We treat software like capital (McBreen, 155) > We build in quality to the software we create. (McBreen, 41) > We sign our work (McBreen, 52) > We put predicable and forgiving user interfaces on our software > (McBreen, 163) > We design software for testing and maintenance (McBreen, 155, 165) > We value long lived technologies and languages and are wary of > proprietary tools (McBreen, 87) > We drive our development with tests (UncleBob)
> The Craftsman's Rhythm (steadily adding value) > We say no to prevent doing harm to our craft and our projects > (Summit) > We keep projects from spinning in circles(Doug) > We value quality over feature set of delivery data (McBreen, 64) > We build long-lived application and support them throughout their > life (McBreen, 65, 80) > We deliver what our customers really need, not just what they ask for > (McBreen, 83) > We automate every task possible (especially testing) (McBreen, 63) > We don't wait for complete definition before beginning (UncleBob) > We never allow ourselves to be blocked (UncleBob)
> The Craftsman's Community (a community of professionals) > We work in a community with other craftsmen (Summit) > Our livelihoods and reputations are interdependent (Doug) > We will help other craftsmen in their journey (Summit) > We can point to the people who influenced us and who we influenced > (Summit) > We take on Apprentices and put them in an environment where they can > learn our craft for themselves (McBreen, 97) > We recommend other craftsmen, hanging our own reputation on their > performance. (McBreen, 38) > We accept that different craftsmen are better suited for one kind of > job over another (Jim Highsmith via McBreen, 65)
> The Craftsman's Customer (productive partnerships) > We are proud of our work and the manner of our work (Summit) > We take responsibility for the code we write (Summit) > We are proud of our portfolio of successful projects (Summit) > We take our customer's needs as seriously as they do (UncleBob) > We build Trust and respect with our customers (McBreen, 54) > We build long term relationships with customers (McBreen, 65) > We desire demanding users (McBreen, 147) > We consistently exceed and raise our customer's expectations of > quality software (Hoover)
It is important to differentiate "craftsmanship" from a particular
school of craftsmanship. Many of us may consider TDD as an essential
ingredient of our school, but there are valid schools that font
include it.
So are these principles general, or are they specific to a school? The
risk of the former is dilution, the risk of the latter is exclusion.
Sent from my iPhone
On Mar 12, 2009, at 6:56 AM, Dave Hoover <dave.hoo...@gmail.com> wrote:
> I would start by removing the following principles...
> "We drive our development with tests" (UncleBob)
> I could be persuaded (by Uncle Bob) to change my mind on this, but I
> don't see how this relates to Craftsmanship. It feels too low-level.
> "We keep projects from spinning in circles" (Doug)
> This really doesn't tell anyone anything. No approach could disagree
> with this and therefore I don't think it's carrying its own weight.
> "We don't wait for complete definition before beginning" (UncleBob)
> "We never allow ourselves to be blocked" (UncleBob)
> Again, these feel too low-level. I'd prefer that we not redefine XP as
> Software Craftsmanship.
> There are others that I'd want to refine and reword. But I'll start
> with the above.
> Best,
> --Dave
> On Wed, Mar 11, 2009 at 7:40 PM, Doug <d...@8thlight.com> wrote:
>> Craftsmen,
>> In another consensus building effort, I've tried to gather up all the
>> principles that have been batted around lately.
>> Where possible, I've indicated the origin of the principle to the
>> best
>> of my knowledge. I've pulled many directly out of McBreen's book.
>> Some of those we haven't really discussed yet. Those credited to
>> UncleBob are from his "Craftsmanship and Ethics" talk. Other credits
>> are from list activity.
>> Feel free to add to the page, but please don't delete (yet).
>> The Craftsman
>> We follow our chosen practices deliberately, to ensure
>> quality in our
>> work" (Summit / BenRady)
>> We adopt development processes to suit our own unique
>> abilities and
>> talents (McBreen, 35)
>> We are skill-centric rather than process-centric. (Ade)
>> We are generalists (McBreen, 21)
>> We achieve technical and design excellence through
>> continuous and
>> deliberate learning and practice. (Enrique)
>> We build our reputations on delivered quality (McBreen, 37)
>> We desire to remain Software Craftsmen and write code for
>> our entire
>> careers(McBreen, 73)
>> We respect master craftsmen as the key to Software
>> Craftsmanship
>> (McBreen, 85)
>> The Craftsman's Product (well-crafted software)
>> We write code that is easy to read, understand and modify. >> (Summit)
>> We believe the code is also an end, not just a means.(Summit)
>> We treat software like capital (McBreen, 155)
>> We build in quality to the software we create. (McBreen, 41)
>> We sign our work (McBreen, 52)
>> We put predicable and forgiving user interfaces on our
>> software
>> (McBreen, 163)
>> We design software for testing and maintenance (McBreen,
>> 155, 165)
>> We value long lived technologies and languages and are wary of
>> proprietary tools (McBreen, 87)
>> We drive our development with tests (UncleBob)
>> The Craftsman's Rhythm (steadily adding value)
>> We say no to prevent doing harm to our craft and our projects
>> (Summit)
>> We keep projects from spinning in circles(Doug)
>> We value quality over feature set of delivery data (McBreen,
>> 64)
>> We build long-lived application and support them throughout
>> their
>> life (McBreen, 65, 80)
>> We deliver what our customers really need, not just what
>> they ask for
>> (McBreen, 83)
>> We automate every task possible (especially testing)
>> (McBreen, 63)
>> We don't wait for complete definition before beginning
>> (UncleBob)
>> We never allow ourselves to be blocked (UncleBob)
>> The Craftsman's Community (a community of professionals)
>> We work in a community with other craftsmen (Summit)
>> Our livelihoods and reputations are interdependent (Doug)
>> We will help other craftsmen in their journey (Summit)
>> We can point to the people who influenced us and who we
>> influenced
>> (Summit)
>> We take on Apprentices and put them in an environment where
>> they can
>> learn our craft for themselves (McBreen, 97)
>> We recommend other craftsmen, hanging our own reputation on
>> their
>> performance. (McBreen, 38)
>> We accept that different craftsmen are better suited for one
>> kind of
>> job over another (Jim Highsmith via McBreen, 65)
>> The Craftsman's Customer (productive partnerships)
>> We are proud of our work and the manner of our work (Summit)
>> We take responsibility for the code we write (Summit)
>> We are proud of our portfolio of successful projects (Summit)
>> We take our customer's needs as seriously as they do
>> (UncleBob)
>> We build Trust and respect with our customers (McBreen, 54)
>> We build long term relationships with customers (McBreen, 65)
>> We desire demanding users (McBreen, 147)
>> We consistently exceed and raise our customer's expectations
>> of
>> quality software (Hoover)
These principles are general: "The Principles of Software Craftsmanship"
If schools of craftsmanship want to spell out their more exclusive
principles, that would be a different document. Sort of how XP and
Scrum have their own values/principles/practices but co-existin within
the more general Agile manifesto.
> It is important to differentiate "craftsmanship" from a particular
> school of craftsmanship. Many of us may consider TDD as an essential
> ingredient of our school, but there are valid schools that font
> include it.
> So are these principles general, or are they specific to a school? The
> risk of the former is dilution, the risk of the latter is exclusion.
> Sent from my iPhone
> On Mar 12, 2009, at 6:56 AM, Dave Hoover <dave.hoo...@gmail.com> wrote:
>> I would start by removing the following principles...
>> "We drive our development with tests" (UncleBob)
>> I could be persuaded (by Uncle Bob) to change my mind on this, but I
>> don't see how this relates to Craftsmanship. It feels too low-level.
>> "We keep projects from spinning in circles" (Doug)
>> This really doesn't tell anyone anything. No approach could disagree
>> with this and therefore I don't think it's carrying its own weight.
>> "We don't wait for complete definition before beginning" (UncleBob)
>> "We never allow ourselves to be blocked" (UncleBob)
>> Again, these feel too low-level. I'd prefer that we not redefine XP as
>> Software Craftsmanship.
>> There are others that I'd want to refine and reword. But I'll start
>> with the above.
>> Best,
>> --Dave
>> On Wed, Mar 11, 2009 at 7:40 PM, Doug <d...@8thlight.com> wrote:
>>> Craftsmen,
>>> In another consensus building effort, I've tried to gather up all the
>>> principles that have been batted around lately.
>>> Where possible, I've indicated the origin of the principle to the
>>> best
>>> of my knowledge. I've pulled many directly out of McBreen's book.
>>> Some of those we haven't really discussed yet. Those credited to
>>> UncleBob are from his "Craftsmanship and Ethics" talk. Other credits
>>> are from list activity.
>>> Feel free to add to the page, but please don't delete (yet).
>>> The Craftsman
>>> We follow our chosen practices deliberately, to ensure
>>> quality in our
>>> work" (Summit / BenRady)
>>> We adopt development processes to suit our own unique
>>> abilities and
>>> talents (McBreen, 35)
>>> We are skill-centric rather than process-centric. (Ade)
>>> We are generalists (McBreen, 21)
>>> We achieve technical and design excellence through
>>> continuous and
>>> deliberate learning and practice. (Enrique)
>>> We build our reputations on delivered quality (McBreen, 37)
>>> We desire to remain Software Craftsmen and write code for
>>> our entire
>>> careers(McBreen, 73)
>>> We respect master craftsmen as the key to Software
>>> Craftsmanship
>>> (McBreen, 85)
>>> The Craftsman's Product (well-crafted software)
>>> We write code that is easy to read, understand and modify.
>>> (Summit)
>>> We believe the code is also an end, not just a means.(Summit)
>>> We treat software like capital (McBreen, 155)
>>> We build in quality to the software we create. (McBreen, 41)
>>> We sign our work (McBreen, 52)
>>> We put predicable and forgiving user interfaces on our
>>> software
>>> (McBreen, 163)
>>> We design software for testing and maintenance (McBreen,
>>> 155, 165)
>>> We value long lived technologies and languages and are wary of
>>> proprietary tools (McBreen, 87)
>>> We drive our development with tests (UncleBob)
>>> The Craftsman's Rhythm (steadily adding value)
>>> We say no to prevent doing harm to our craft and our projects
>>> (Summit)
>>> We keep projects from spinning in circles(Doug)
>>> We value quality over feature set of delivery data (McBreen,
>>> 64)
>>> We build long-lived application and support them throughout
>>> their
>>> life (McBreen, 65, 80)
>>> We deliver what our customers really need, not just what
>>> they ask for
>>> (McBreen, 83)
>>> We automate every task possible (especially testing)
>>> (McBreen, 63)
>>> We don't wait for complete definition before beginning
>>> (UncleBob)
>>> We never allow ourselves to be blocked (UncleBob)
>>> The Craftsman's Community (a community of professionals)
>>> We work in a community with other craftsmen (Summit)
>>> Our livelihoods and reputations are interdependent (Doug)
>>> We will help other craftsmen in their journey (Summit)
>>> We can point to the people who influenced us and who we
>>> influenced
>>> (Summit)
>>> We take on Apprentices and put them in an environment where
>>> they can
>>> learn our craft for themselves (McBreen, 97)
>>> We recommend other craftsmen, hanging our own reputation on
>>> their
>>> performance. (McBreen, 38)
>>> We accept that different craftsmen are better suited for one
>>> kind of
>>> job over another (Jim Highsmith via McBreen, 65)
>>> The Craftsman's Customer (productive partnerships)
>>> We are proud of our work and the manner of our work (Summit)
>>> We take responsibility for the code we write (Summit)
>>> We are proud of our portfolio of successful projects (Summit)
>>> We take our customer's needs as seriously as they do
>>> (UncleBob)
>>> We build Trust and respect with our customers (McBreen, 54)
>>> We build long term relationships with customers (McBreen, 65)
>>> We desire demanding users (McBreen, 147)
>>> We consistently exceed and raise our customer's expectations
>>> of
>>> quality software (Hoover)
We have to be careful in stating our principle. This craft is blessed
(and cursed) by it's 1000000's of ways of doing things (languages,
paradigms, etc, etc) which makes it nearly impossible to state things
like "do TDD!".
Ade made a good point about proving (through testing, mathematically
or mystical influences) that the code works as promised...
It makes much harder to come up with a reasonable set of principles,
but I think, as Dave says, that the details will be fleshed out in
particular schools/workshops.
> These principles are general: "The Principles of Software Craftsmanship"
> If schools of craftsmanship want to spell out their more exclusive
> principles, that would be a different document. Sort of how XP and
> Scrum have their own values/principles/practices but co-existin within
> the more general Agile manifesto.
> On Thu, Mar 12, 2009 at 10:43 AM, Robert Martin
> <uncle...@objectmentor.com> wrote:
>> It is important to differentiate "craftsmanship" from a particular
>> school of craftsmanship. Many of us may consider TDD as an essential
>> ingredient of our school, but there are valid schools that font
>> include it.
>> So are these principles general, or are they specific to a school? The
>> risk of the former is dilution, the risk of the latter is exclusion.
>> Sent from my iPhone
>> On Mar 12, 2009, at 6:56 AM, Dave Hoover <dave.hoo...@gmail.com> wrote:
>>> I would start by removing the following principles...
>>> "We drive our development with tests" (UncleBob)
>>> I could be persuaded (by Uncle Bob) to change my mind on this, but I
>>> don't see how this relates to Craftsmanship. It feels too low-level.
>>> "We keep projects from spinning in circles" (Doug)
>>> This really doesn't tell anyone anything. No approach could disagree
>>> with this and therefore I don't think it's carrying its own weight.
>>> "We don't wait for complete definition before beginning" (UncleBob)
>>> "We never allow ourselves to be blocked" (UncleBob)
>>> Again, these feel too low-level. I'd prefer that we not redefine XP as
>>> Software Craftsmanship.
>>> There are others that I'd want to refine and reword. But I'll start
>>> with the above.
>>> Best,
>>> --Dave
>>> On Wed, Mar 11, 2009 at 7:40 PM, Doug <d...@8thlight.com> wrote:
>>>> Craftsmen,
>>>> In another consensus building effort, I've tried to gather up all the
>>>> principles that have been batted around lately.
>>>> Where possible, I've indicated the origin of the principle to the
>>>> best
>>>> of my knowledge. I've pulled many directly out of McBreen's book.
>>>> Some of those we haven't really discussed yet. Those credited to
>>>> UncleBob are from his "Craftsmanship and Ethics" talk. Other credits
>>>> are from list activity.
>>>> Feel free to add to the page, but please don't delete (yet).
>>>> The Craftsman
>>>> We follow our chosen practices deliberately, to ensure
>>>> quality in our
>>>> work" (Summit / BenRady)
>>>> We adopt development processes to suit our own unique
>>>> abilities and
>>>> talents (McBreen, 35)
>>>> We are skill-centric rather than process-centric. (Ade)
>>>> We are generalists (McBreen, 21)
>>>> We achieve technical and design excellence through
>>>> continuous and
>>>> deliberate learning and practice. (Enrique)
>>>> We build our reputations on delivered quality (McBreen, 37)
>>>> We desire to remain Software Craftsmen and write code for
>>>> our entire
>>>> careers(McBreen, 73)
>>>> We respect master craftsmen as the key to Software
>>>> Craftsmanship
>>>> (McBreen, 85)
>>>> The Craftsman's Product (well-crafted software)
>>>> We write code that is easy to read, understand and modify.
>>>> (Summit)
>>>> We believe the code is also an end, not just a means.(Summit)
>>>> We treat software like capital (McBreen, 155)
>>>> We build in quality to the software we create. (McBreen, 41)
>>>> We sign our work (McBreen, 52)
>>>> We put predicable and forgiving user interfaces on our
>>>> software
>>>> (McBreen, 163)
>>>> We design software for testing and maintenance (McBreen,
>>>> 155, 165)
>>>> We value long lived technologies and languages and are wary of
>>>> proprietary tools (McBreen, 87)
>>>> We drive our development with tests (UncleBob)
>>>> The Craftsman's Rhythm (steadily adding value)
>>>> We say no to prevent doing harm to our craft and our projects
>>>> (Summit)
>>>> We keep projects from spinning in circles(Doug)
>>>> We value quality over feature set of delivery data (McBreen,
>>>> 64)
>>>> We build long-lived application and support them throughout
>>>> their
>>>> life (McBreen, 65, 80)
>>>> We deliver what our customers really need, not just what
>>>> they ask for
>>>> (McBreen, 83)
>>>> We automate every task possible (especially testing)
>>>> (McBreen, 63)
>>>> We don't wait for complete definition before beginning
>>>> (UncleBob)
>>>> We never allow ourselves to be blocked (UncleBob)
>>>> The Craftsman's Community (a community of professionals)
>>>> We work in a community with other craftsmen (Summit)
>>>> Our livelihoods and reputations are interdependent (Doug)
>>>> We will help other craftsmen in their journey (Summit)
>>>> We can point to the people who influenced us and who we
>>>> influenced
>>>> (Summit)
>>>> We take on Apprentices and put them in an environment where
>>>> they can
>>>> learn our craft for themselves (McBreen, 97)
>>>> We recommend other craftsmen, hanging our own reputation on
>>>> their
>>>> performance. (McBreen, 38)
>>>> We accept that different craftsmen are better suited for one
>>>> kind of
>>>> job over another (Jim Highsmith via McBreen, 65)
>>>> The Craftsman's Customer (productive partnerships)
>>>> We are proud of our work and the manner of our work (Summit)
>>>> We take responsibility for the code we write (Summit)
>>>> We are proud of our portfolio of successful projects (Summit)
>>>> We take our customer's needs as seriously as they do
>>>> (UncleBob)
>>>> We build Trust and respect with our customers (McBreen, 54)
>>>> We build long term relationships with customers (McBreen, 65)
>>>> We desire demanding users (McBreen, 147)
>>>> We consistently exceed and raise our customer's expectations
>>>> of
>>>> quality software (Hoover)
I believe we need to mention something under The Craftsman's Product
(well-crafted software) regarding defects. Specifically McBreens book
says something like, and I don't have my copy with me, a Craftsman
delivers with 0 known defects. I realize that 0 known defects is
pretty controversial, so let me explain a little as to why I think
it's important.
On a product I worked on about a lifetime ago, there was a "quality"
policy. That policy was "New code must have 0 showstoppers or high
defects, existing code must have 0 show stoppers." Now when I left
that company the system they shipped had around 2000 open defects, but
it was okay because they were medium and low! Well except for the
high ones that the customer was used too!
So obviously that level of suck is not acceptable to a craftsman, but
where do we draw the line. Is 5 defects okay? 200? 8%? In my
opinion, and McBreen's as well, the only truly acceptable answer is 0.
So I would add, to the Craftsman's Product,
We allow 0 known defects.
I've softened the language on that several times, and that just allows
weaseling. This isn't the same as perfect code. We are human, and we
will release > 0 unknown defects, but releasing code with bugs you
know exist is irresponsible.
> I believe we need to mention something under The Craftsman's Product
> (well-crafted software) regarding defects. Specifically McBreens book
> says something like, and I don't have my copy with me, a Craftsman
> delivers with 0 known defects. I realize that 0 known defects is
> pretty controversial, so let me explain a little as to why I think
> it's important.
> On a product I worked on about a lifetime ago, there was a "quality"
> policy. That policy was "New code must have 0 showstoppers or high
> defects, existing code must have 0 show stoppers." Now when I left
> that company the system they shipped had around 2000 open defects, but
> it was okay because they were medium and low! Well except for the
> high ones that the customer was used too!
> So obviously that level of suck is not acceptable to a craftsman, but
> where do we draw the line. Is 5 defects okay? 200? 8%? In my
> opinion, and McBreen's as well, the only truly acceptable answer is 0.
> So I would add, to the Craftsman's Product,
> We allow 0 known defects.
> I've softened the language on that several times, and that just allows
> weaseling. This isn't the same as perfect code. We are human, and we
> will release > 0 unknown defects, but releasing code with bugs you
> know exist is irresponsible.
>>> We allow 0 known defects. >> personally, i think that's overkill. > Is it?
I think a real Craftsman would know about the need to balance things, and that sometimes "ship it!" really does outweigh "but what about those 5 low-priority open bugs?".
> It doesn't mean that the software is bug free, but enhances the value > of testing.
Apologies, I'm not yet catching on to what you mean by that. (1) Presumably we all know you prove software of any real size to be 100% bug-free (and one would have to define 'bug' even so), so I assume that isn't relevant. (2) "Requiring 0 known defects enhances the value of testing" doesn't make sense to me, I don't see the causality there. If anything, I'd just /avoid/ testing so I can say there are 0 known defects?!
> I'd say it means that a craftsman will make sure that he fixes those 2000 > known bugs before releasing...
What are the implications of that decision? How many defects can be fixed in a given period of time? What if fixing just one of those 2000 bugs addresses 90% of the customer complaints? Do you delay releasing that fix until the others are complete? I would never impose that limitation on my client.
On 12 Mar 2009, at 20:46, Carl Hume <carl.h...@gmail.com> wrote:
> I'd say it means that a craftsman will make sure that he fixes those
> 2000 known bugs before releasing...
> What are the implications of that decision? How many defects can be
> fixed in a given period of time? What if fixing just one of those
> 2000 bugs addresses 90% of the customer complaints? Do you delay
> releasing that fix until the others are complete? I would never
> impose that limitation on my client.
I think that goes a bit inthe lines of what Corey phrased as IKEA vs
Amish. I am sure that a company would nor have that many bugs in their
system. So this situation would not exist in the first place.
On the other hand it would be possible that a company just hired a
team of craftsmen to solve their terrible pain with their software, in
which case I would say that a staged approach should (and possibly
would) be taken.
|
