View this page "Principles of Software Craftsmanship"

[Doug]

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).

http://groups.google.com/group/software_craftsmanship/web/principles-of-software-craftsmanship

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)

[James Martin]

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.


What do you think?


Thanks,
James.

[Jason Gorman]

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).
>

> http://groups.google.com/group/software_craftsmanship/web/principles-...

[Michael Wilson]

Eh. This loses me. A lot of these are really bad.



This: http://manifesto.softwarecraftsmanship.org/ I like.

[Denny Abraham]

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).

[Dave Hoover]

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!

[Doug Bradbury]

Dave,

You are right. I'm hoping that people will take the time to pick
apart these principles, add to them, argue against some.

I imagine the list getting bigger first as people add their ideas and
then smaller as we refine them.

Doug

[Dave Hoover]

Jason, I'm not groking what you mean.

[Adewale Oshineye]

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.
====

2009/3/12 Doug <do...@8thlight.com>:

[Dave Hoover]

This is a great list. It's easier to digest if you click through to
the web page Doug created:
http://groups.google.com/group/software_craftsmanship/web/principles-of-software-craftsmanship

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

[Dave Hoover]

This is a great list. It's easier to digest if you click through to
the web page Doug created:
http://groups.google.com/group/software_craftsmanship/web/principles-of-software-craftsmanship

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 <do...@8thlight.com> wrote:
>

[Robert Martin]

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

[Dave 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.

[Enrique Comba Riepenhausen]

I agree with Uncle Bob and Dave!

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.

2009/3/12 Dave Hoover <dave....@gmail.com>:

--
Enrique Comba Riepenhausen
[@]: <eco...@gmail.com>
[w]: <http://www.nexwerk.com>

[payto...@gmail.com]

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.

[Raoul Duke]

> So I would add, to the Craftsman's Product,
>
> We allow 0 known defects.

personally, i think that's overkill.

sincerely.

[Enrique Comba Riepenhausen]

Hi Eric,

I like it! And you just reminded me that I have to reread the book :)

I would phrase it somewhere in the lines of:

We will not release software that is known to have defects.

Not sure, sounds more complex than you phrased it and says the same...

Just as food for though:

0 known bugs is controversial indeed as we can achieve it without
testing...

Enrique Comba Riepenhausen

On 12 Mar 2009, at 20:05, "er...@8thlight.com" <payto...@gmail.com>
wrote:

[Enrique Comba Riepenhausen]

>
>
>> So I would add, to the Craftsman's Product,
>>
>> We allow 0 known defects.
>
> personally, i think that's overkill.
>

Is it?
It doesn't mean that the software is bug free, but enhances the value
of testing.

Enrique

>
> >

[Carl Hume]

It means Craftsman do not work on legacy products with 2000 defects...

Cheers!
Carl

[Raoul Duke]

>>> 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?!

sincerely.

[Raoul Duke]

> It means Craftsman do not work on legacy products with 2000 defects...

Why not? What if the job is to move that pos product more towards
something less stinky? Is that beneath a Craftsman?

sincerely.

[Carl Hume]

That was my point :)

Cheers!
Carl

[Enrique Comba Riepenhausen]

I'd say it means that a craftsman will make sure that he fixes those 2000 known bugs before releasing... 

Cheers!
Carl

[Carl Hume]

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.

Cheers!
Carl

[Enrique Comba Riepenhausen]

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.

>
>
> Cheers!
> Carl
>
>
> >

[Carl Hume]

On Thu, Mar 12, 2009 at 4:51 PM, Enrique Comba Riepenhausen <eco...@gmail.com> wrote:

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.

Agreed.

How does "we do not introduce any known defects into the system" sound?

Cheers!
Carl

[Markus Gaertner]

The Craftsman

We achieve technical and design excellence through continuous and
deliberate learning and practice. (Enrique)

and

The Craftsman's Community (a community of professionals)

We can point to the people who influenced us and who we influenced (Summit)

have some implications vice versa. I'm uncertain, whether this fact should be
made clearly. Something like this dropped into my mind:
We exchange thoughts and practices among our community in order to improve our
level of mastery of the craft.

Another addition I would like to throw in:
We protect and improve a portfolio of technical practices to excel and delight
our customer in varying situations.
But maybe this is just a combination of two or three of the already mentioned
practices.

One last thing I'm missing:
We regularly reflect upon our practices and projects and identify areas of
improvement to delight the customers in our next projects.

Kind regards
Markus Gärtner

> The Craftsman's Product (well-crafted software)

[Enrique Comba Riepenhausen]

2009/3/12 Carl Hume <carl...@gmail.com>:

We could add that one to the 0 bugs principle...

We will not release software that is known to have defects and never
introduce any know bug into a system.

Actually I don't like that phrasing... (my english sucks again ;) ).

Any ideas how to phrase that correctly?

Enrique


>
> Cheers!
> Carl

[Enrique Comba Riepenhausen]

> One last thing I'm missing:
> We regularly reflect upon our practices and projects and identify areas of
> improvement to delight the customers in our next projects.

Isn't that implied in the continuous and deliberate learning and
practice? It might not and we might need to, either rephrase that one
or simply state another principle, not sure...

Cheers,

Enrique

[Nevin ":-)"]

On Mar 12, 3:05 pm, "e...@8thlight.com" <paytonru...@gmail.com> wrote:
> 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.

It's controversial because we don't know how to achieve it without
sacrificing either time to market or feature sets.

This is the polar opposite of "real artists ship".

Perfect is the enemy of good.

What are the non-trivial software projects that have shipped
defect-free which have developed using Software Craftsmanship (or any
other way for that matter)? If this is a tenet, there should be
plenty
of real products which have achieved it.

Every development methodology wants to minimize defects. Saying that
we are better in this respect than everybody else without saying how
and proving that we have actually done it time and time again is just
not a good idea.

> but releasing code with bugs you
> know exist is irresponsible.

Not striving to produce software that minimizes defects would be
irresponsible. Not searching for possible defects would be
irresponsible. Not documenting known bugs would be irresponsible.
But what to do about known bugs is as much a business decision as it
is a technical one.

In the zero-defect world, is it irresponsible to keep shipping a
product if *any* defects are discovered after release?
--
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404

[Dave Hoover]

On Thu, Mar 12, 2009 at 4:10 PM, Markus Gaertner
<mgae...@googlemail.com> wrote:
> We exchange thoughts and practices among our community in order to improve our
> level of mastery of the craft.

I'm just not sure if that carries enough distinction in this day and
age. Nearly every community focused on a technology or process would
be able to agree to that principle. I believe we need to look for our
unique principles, the principles that set us apart.

> One last thing I'm missing:
> We regularly reflect upon our practices and projects and identify areas of
> improvement to delight the customers in our next projects.

I think that's too close to the last agile principle on:
http://agilemanifesto.org/principles.html

Keep 'em coming, tho!

[Scott Seely]

A lot of the defects that a system encounters may not be worth fixing. For
example, if I know that the system fails under a load of 5000 users, as a
craftsman, I will set limits to make sure that something smart happens when
user 4999 logs in. I can happily ship with that defect.

If my color scheme doesn't handle folks with limited sight, but my users all
have perfect vision, I will ship with a low contrast scheme that the users
like.

If my application has no clue about localization in 100 locations, but all
my users speak English, I will ship.

There are defects and then there are defects. Some defects don't matter.
This is why bugs are triaged and prioritized based on effect. Some defects
don't have an impact on your user population, so they don't need to be
addressed.

[Dave Hoover]

On Thu, Mar 12, 2009 at 3:34 PM, Raoul Duke <rao...@gmail.com> wrote:
>
>>>> 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?".

I tend to lean toward exposing that decision to the business owner,
though it's a judgment call. Reducing the defect count to 0 can mean
huge delays in releases that could kill the business. In most cases,
though, the principle is about being rigorous and holding ourselves to
a high standard. I don't have a good principle, though, to describe
what I'm getting at. Arg.

[Raoul Duke]

hi,

good point.

> I tend to lean toward exposing that decision to the business owner,
> though it's a judgment call.  Reducing the defect count to 0 can mean
> huge delays in releases that could kill the business.  In most cases,
> though, the principle is about being rigorous and holding ourselves to
> a high standard.  I don't have a good principle, though, to describe
> what I'm getting at.  Arg.

something like "O God give me the strength to change the things I can
and to accept things that I can't and otherwise go talk with BizDev."
:-)

[Dave Hoover]

That reminds me of the Serenity Prayer for software developers.
http://twitter.com/apprentice/status/937348129

[James Martin]

On Fri, Mar 13, 2009 at 12:38 AM, Adewale Oshineye <ade...@gmail.com> wrote:

- 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.

Ade, thanks for clearing this one up. I misunderstood the intention of it when you quoted just the first sentence in another thread.

What a difference an example makes! :)


Thanks,
James.

[David Stanek]

On Thu, Mar 12, 2009 at 5:02 PM, Carl Hume <carl...@gmail.com> wrote:
>
> How does "we do not introduce any known defects into the system" sound?
>

To be honest it seems quite silly. Nobody intentionally introduces
bug. Not even the crappy programmers.

In the end *when* issues are found in the system it is really up to
the customer to figure out which ones need to be addressed before the
next release. If you have the release often mentality then you most
certainly release with known issues.

--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek

[Doug Bradbury]

We deliver our work to our customer without known defect.


1) We deliver (positive statement, the software is delivered)
2) Our work (limits the scope to software we write, not someone else's
in a legacy system. Our approach to a legacy system could be covered
in another principle)
3) to our customer (if the customer finds a defect after we have
delivered, they make the decision about releasing or shipping. Our
response at that point is covered in another principle like "We take
responsibility for the code we write." It's up to us to fix it.)

Doug

[David Stanek]

On Fri, Mar 13, 2009 at 8:02 AM, Doug Bradbury <do...@8thlight.com> wrote:
>
>
> We deliver our work to our customer without known defect.
>
>

> 3) to our customer (if the customer finds a defect after we have
> delivered, they make the decision about releasing or shipping.  Our
> response at that point is covered in another principle like "We take
> responsibility for the code we write."  It's up to us to fix it.)
>

What if we are working side by side with our stakeholders in an agile
way? We are in the middle of a sprint and a bug is discovered. They
have the option to have us fix the bug or continue on our current
stories. At the end of the sprint we may still release if the customer
wants to.

[Doug Bradbury]

I'm assuming you are talking about a defect in a previous sprint's work.

I would fix the bug and deliver the current stories and figure out how
not to make the same mistake again.

To me, that's what it means to be responsible for the code I write.

Doug

[Enrique Comba Riepenhausen]

On 13 Mar 2009, at 12:02, Doug Bradbury <do...@8thlight.com> wrote:

>
>
> We deliver our work to our customer without known defect.
>
>
> 1) We deliver (positive statement, the software is delivered)
> 2) Our work (limits the scope to software we write, not someone else's
> in a legacy system. Our approach to a legacy system could be covered
> in another principle)
> 3) to our customer (if the customer finds a defect after we have
> delivered, they make the decision about releasing or shipping. Our
> response at that point is covered in another principle like "We take
> responsibility for the code we write." It's up to us to fix it.)
>

+1 short and to the point!

Well spelled Doug!

Enrique

[Dave Hoover]

On Fri, Mar 13, 2009 at 7:11 AM, David Stanek <dst...@dstanek.com> wrote:
> What if we are working side by side with our stakeholders in an agile
> way? We are in the middle of a sprint and a bug is discovered. They
> have the option to have us fix the bug or continue on our current
> stories. At the end of the sprint we may still release if the customer
> wants to.

Yes, this is a great question. And this sort of approach is why I like
the phrase "as intended" because it reflects the ambiguity of this
problem while still pointing us in the right direction. I agree with
Carl Hume's suggestion:

"As an aspiring craftsman, I can prove everything I write works as intended."

This is flexible enough that it handles rigorously specified cases, as
well as deeply collaboratively cases. In one case the intention has
been documented, in the other case the intention is found through
interaction. In either case, a craftsman has a responsibility to
ensure that the customer's intentions were fulfilled by the system.

[Carl Hume]

On Fri, Mar 13, 2009 at 6:41 AM, David Stanek <dst...@dstanek.com> wrote:

On Thu, Mar 12, 2009 at 5:02 PM, Carl Hume <carl...@gmail.com> wrote:
>
> How does "we do not introduce any known defects into the system" sound?
>

To be honest it seems quite silly. Nobody intentionally introduces
bug. Not even the crappy programmers.

I have worked with people who have "finished" features, introduced a problem in the process, decided it was too tough to deal with right now and moved on to the next feature, all without telling the client what was going on.

This is not the behavior of a craftsman.
 

In the end *when* issues are found in the system it is really up to
the customer to figure out which ones need to be addressed before the
next release. If you have the release often mentality then you most
certainly release with known issues.

It depends on "when" the issues are found, and what the impact is.

If the problem I find endangers the stories I've committed to for the iteration, then I will get the client involved post-haste.  If the problem I find will take an hour to fix, I fix it.

I agree 100% that it is the client's call to decide if they are willing to release with known bugs, and it's up to them to prioritize fixing known defects from past releases against stories for new functionality.

Cheers!
Carl

[Markus Gaertner]

After looking over the list again, I just seem to find some nifty things that
seem to deal a bit with consistency. While doing this I was wondering if the
categories will be kept. If not, my points could turn out irrelevant.

Another one I just noticed about the order in the community part:

We take on Apprentices and put them in an environment where they can learn
our craft for themselves (McBreen, 97)
We will help other craftsmen in their journey (Summit)
We can point to the people who influenced us and who we influenced (Summit)
We recommend other craftsmen, hanging our own reputation on their
performance. (McBreen, 38)

Putting the apprenticeship in front of the other three makes the chain more
consecutive I think. The apprentice, journeyman, master is reflected by the
ordering.

We take responsibility for the code we write.
makes more sense to me in the well-crafted software part or the very first
definition of software craftsman to me. It needs more context to be kept in the
productive partnerships part I think. Maybe it's just a kind of redundancy with
"We build long-lived applications and support them throughout their life".
(Note that the plural of application is missing on the web.)

The following is a combination of McBreen 54 and 65:
We build trust, respect and long-term releationships with our customers.

McBreen 85, We respect master crasftsman as the key to Software Craftsmanship
is some kind of in the middle between Craftsmanship in general and the
community of professionals.

The Craftsman's Rhythm seems a to be too small to me. Unfortunately I don't
know what else to put into there.

We sign our work. and We take responsibility for the code we write. look the
same to me. If I sign my work, I'm sending out the signal, that I am
responsible for this part of the application, this application or the overall
project. Therefore I put a sign on it, so that anyone getting to the system in
the future will know.

Kind regards
Markus Gärtner

[Mark Levison]

I can't sign onto a promise of zero bugs. What if the we demonstrate the product to the customer in a demo and say there are bugs (showing them) and the customer says I want it now inspite of the bugs? Are we not craftsmen because we are meeting the customers needs?

0 is the goal. We must always improve the product but sometimes the customer is wants software enough that they will accept bugs.

Counter proposal:

A craftsmen fixes bugs as they find them always working to improve overall quality. When a craftsmen can't fix a bug immediately the explain/show the bug to the customer and are honest about the impact.

--
Perhaps it can be argued that this statement is too wooly and not absolute - there are many occasions where the absolute is inappropriate.


Mark

On Thu, Mar 12, 2009 at 4:05 PM, er...@8thlight.com <payto...@gmail.com> wrote:

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.

--
Cheers
Mark Levison
Blog: http://www.notesfromatooluser.com/
Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html

[Denny Abraham]

I think a craftsman knows about and admits his bugs and strives to fix
them. Being human, means their software is rarely bugless. Being
craftsman means they're always accountable for leaving a codebase with
fewer defects than they found it, whenever they work on it.

[David Stanek]

Exactly my point. So saying 0 bugs isn't correct. We certainly should
aim at producing the best possible product with the least amount of
defects. In the end 0 is not always necessary.

[Curtis Cooley]

While I can't control how many bugs are in the system at any one time,
after all, bugs are usually unknown, I can control my behavior. By
that I mean, I can choose to always seek out and find new tools,
practices, habits, etc.. that are known to reduce bugs and integrate
them into my tool set.
--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.

[James Martin]

On Fri, Mar 13, 2009 at 9:41 PM, David Stanek <dst...@dstanek.com> wrote:

In the end *when* issues are found in the system it is really up to
the customer to figure out which ones need to be addressed before the
next release. If you have the release often mentality then you most
certainly release with known issues.

This is along the right lines, I think.

Elisabeth Hendrickson just blogged about bugs in an Agile context[1], but I think the principle can be applied to sw craftmanship without being prescriptive to Agile:

"Before we declare a story “Done,” if we find something that would violate the Product Owner’s expectations, we fix it. We don’t argue about it, we don’t debate or triage, we just fix it. This is what it means to have a zero tolerance for bugs."

So perhaps the principle should be:

"As craftsmen we have a zero tolerance for software that violates the customer's expectations"

This actually ties to the values from the manifesto; well-crafted software (we've met the customer's expectations) and steadily adding value (the customer helps us to determine what will be valuable now and in the future).


Thanks,
James.

[1] http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/

[Tore Vestues]

I really appreciate this initiative. Great work everyone.

Here's my two cents:

In his tool belt, the craftsman has knowledge, techniques, principles,
and practices. But the tools vary from craftsman to craftsman. While
some are wielding OO and its principles with great accuracy and
creates great software that way, others might be doing the same in
totally different paradigms. But they are still all great craftsmen.
We must be careful so that our principles do not touch specific
schools, it might very soon rule out people we do not want to rule
out.

On the principles: The master craftsman cares greatly about his craft.
To me, trying to create great work is the core of craftsmanship.
Therefore I think "Sign your work" (from pragmatic programmer) says it
all. It’s all about doing a good job, enough to be proud of it.

- Tore Vestues
http://tore.vestues.no

[Markus Gaertner]

You tool belt picture describes pretty much what I was unable to express. The
key point is, that a craftsman learns a set of tools she might need at work,
maintains this set, expands her learned abilites and is able to decide which
tool to use in the situation at hand. Some years ago software testers already
noticed this and introduced the context-driven school of testing, which reminds
me of pretty much the same here.

Kind regards
Markus Gärtner

[Jason Gorman]

By the same token, I think we need to be careful about opening the
floodgates to what I would call "faux contextualists" who are actually
just using contextualism as an excuse for lazy intellectual
relativism. I'm finding increasingly that people are using context-
driven arguments as a smoke screen for - when it comes down to it -
not applying ANY practices effectively. (i.e., the "A hammer isn't
always appropriate, which is why I don't carry a hammer" argument)

Jason Gorman

> >http://tore.vestues.no- Hide quoted text -
>
> - Show quoted text -

[Markus Gaertner]

That's the negative side of the medal. The key idea from my side is, that I
maintain twelve hammer's for every circumstance where I might prefer one or the
other, despite carrying no hammer at all. And as a craftsman I would expect
from a master to invent a 13th hammer and sell it to the community.

Kind regards
Markus Gärtner

[Dave Hoover]

On Sat, Mar 14, 2009 at 2:48 AM, Tore Vestues <tore.v...@gmail.com> wrote:
> On the principles: The master craftsman cares greatly about his craft.
> To me, trying to create great work is the core of craftsmanship.
> Therefore I think "Sign your work" (from pragmatic programmer) says it
> all. It’s all about doing a good job, enough to be proud of it.

Well said. I think that's a great point and is a more distinctive
practice of craftsmanship than focusing on bug counts.

+1 for "Sign Your Work"

Best,

Dave Hoover
//obtiva: Agility applied. Software delivered.

[Kim Gräsman]

Hi Dave,

On Thu, Mar 12, 2009 at 14:56, Dave Hoover <dave....@gmail.com> wrote:
>
> "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.

I don't know that I have seen "We never allow ourselves to be blocked"
in any of the more process-centric principle sets.

It's one I've invented for myself, and it made me happy to see it
spelled out. I think it's crucial, but maybe not for the craftsmanship
movement... Though I think it's the mark of a strong professional to
take matters into their own hands rather than becoming victims of the
environment.

Dunno. I kinda like it :-)

- Kim

[John Christensen]

Generally speaking, I think this is a good list of principles. I find myself in fundamental agreement with several other posters, though, about the agile principles that have been highlighted.

Specifically, I think we're repeating ourselves in "The Craftsman's Product" between "We design software for testing and maintenance (McBreen, 155, 165)", "We drive our development with tests (UncleBob)", and "We build in quality to the software we create. (McBreen, 41)". I would reduce that to the first principle, personally, since I think its the right balance of specificity ("We drive our development with tests" being too specific and seeming to proscribe a particular design methodology) and generality ("We build in quality to the software we create" goes in the opposite direction - its too vague).

That said - I'm also not sure about the principle in "The Craftsman", "We are generalists (McBreen, 21)". While I do believe myself to be a generalist, as this field gets bigger and more complex I can definitely see the need for specialists. I'm not entirely sure that someone who has specialized in an area like low-resources programming, or in writing memory management code in general cannot be a craftsman. That said - I think this is striking at an important point, that everyone needs to at least be aware of the world outside of their office.



John Christensen
http://www.linkedin.com/in/netbard

"Its OK if I get hurt.
I want to live passionately and intensely
without turning my eyes away."
- Rhythm Emotion, Gundam Wing

On Wed, Mar 11, 2009 at 8:40 PM, Doug <do...@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).

http://groups.google.com/group/software_craftsmanship/web/principles-of-software-craftsmanship

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)

[Dave Hoover]

On Mon, Mar 16, 2009 at 8:35 PM, John Christensen <net...@gmail.com> wrote:
> That said - I'm also not sure about the principle in "The Craftsman", "We
> are generalists (McBreen, 21)". While I do believe myself to be a
> generalist, as this field gets bigger and more complex I can definitely see
> the need for specialists. I'm not entirely sure that someone who has
> specialized in an area like low-resources programming, or in writing memory
> management code in general cannot be a craftsman. That said - I think this
> is striking at an important point, that everyone needs to at least be aware
> of the world outside of their office.

A specialist is not a craftsman. If someone is amazingly good at
low-resources programming and has no other significantly developed
development skills, *and* is not attempting to improve any other
skills, then that person does not fit the definition of a craftsman.
And that's OK. We need specialists. And we need craftsman. Being a
specialist is a great and necessary thing.

For example, last week I hired a local database specialist to come
pair with me for 4 hours so that he could advise me on next steps for
MySQL optimizations for http://madmimi.com. He has crazy deep
knowledge of database design, optimization, and maintenance. That is a
very good thing for our industry to have people like that. And he is a
database specialist, not a craftsman.

[Olof Bjarnason]

2009/3/17 Dave Hoover <dave....@gmail.com>:

Maybe he is a database systems craftsman?

>
> >
>



--
Min blogg:
http://olofb.wordpress.com
[My blog, in Swedish]

[Adewale Oshineye]

On 17 Mar 2009, at 12:52, Olof Bjarnason <olof.bj...@gmail.com>
wrote:

Good point.

However this group is about _software_ craftsmanship. There's nothing
wrong with being a specialist. It is an admirable and necessary role.
There's also nothing wrong with software craftsmen who choose to spend
some portion of their career building up expertise in some niche.

However if you want to build and maintain systems that deliver
business value you need more than an assortment of specialists. You
need people who can take responsibility for the entire system by
leveraging the expert contributions of others rather than becoming
ivory tower architects.

[Olof Bjarnason]

2009/3/17 Adewale Oshineye <ade...@gmail.com>:

I think a software craftsman is a kind of specialist - [s]he is
specialized in developing software of high quality, using whatever
tools he's given.

It's just a matter of focus.

[Dave Hoover]

On Tue, Mar 17, 2009 at 9:33 AM, Olof Bjarnason
<olof.bj...@gmail.com> wrote:
> I think a software craftsman is a kind of specialist - [s]he is
> specialized in developing software of high quality, using whatever
> tools he's given.

Good point. And well said.

[Enrique Comba Riepenhausen]

Didn't think it that way, Olof, but it makes sense :)

2009/3/17 Dave Hoover <dave....@gmail.com>:

--
Enrique Comba Riepenhausen
[@]: <eco...@gmail.com>
[w]: <http://www.nexwerk.com>

[Paul Pagel]

A specialized generalist?

[Enrique Comba Riepenhausen]

I think more of a person specialized in software development... I.e. a
generalist for other members of the software industry, but a
specialist in a wider area for people from the outside... oh bummer!
ok you win ;)

2009/3/17 Paul Pagel <pa...@8thlight.com>:

[Paul Pagel]

I agree the point here is that a craftsman learns all the skills
necessary to complete an application. I can do front end development,
db integration, web development, etc. well enough to deliver a high
quality software application.

[Heinrich Breedt]

Ahh, just call me special, and I am happy :P

[Doug Bradbury]

How about this?

'We build competency in a broad range of languages and technologies to
meet the needs of our customers.'

Doug

[Dave Hoover]

On Sun, Mar 22, 2009 at 9:27 AM, Doug Bradbury <do...@8thlight.com> wrote:
>
>
> How about this?
>
> 'We build competency in a broad range of languages and technologies to
> meet the needs of our customers.'

+1

[Doug Bradbury]

Markus,

This was all very good feedback. I've incorporated it into the doc on
the google group.

I'm not sure if the categories will remain or not. For now I find
them helpful for the sake of breaking down such a big list.

Doug

[phil76]

Guys,

I really like the Software Craftsmanship idea and agree with the above
mentioned. I'm also giving a presentation on the topic at Euruko.

I think it would be very helpful to cut down on the pathos in
language. You don't have to sound like a religion to be taken
seriously, I believe the contrary is the case.

Kind regards,
Phillip

[J. B. Rainsberger]

Thanks for your comment, Phillip. I don't follow the postings here
with a magnifying glass, so I have missed some of the
religious-sounding language you mention. Can you quote an example or
two to help me out?
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice
Register for Agile 2009 at http://www.agileregistration.org