The Software Craftsman's Ethic

[Doug Bradbury]

Craftsmen,

I've been working together with a few people on that list of principles / ethics that we were trying to hash out earlier on the list.  What do you think of this both in form and content?

Doug

You might to prefer to view the doc on google:

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

********* The Software Craftsman's Ethic *******************

We Care

We consider it our responsibility

  to gain the trust of the businesses we serve;

    therefore, we

      take our customer's problems as seriously as they do and

      stake our reputation on the quality of the work we produce.

We Practice

We consider it our responsibility

  to write code that is defect-free, proven, readable, understandable and malleable;

    therefore, we

      follow our chosen practices meticulously even under pressure and

      practice our techniques regularly.

We Learn

We consider it our responsibility

  to hone our craft in pursuit of mastery;

    therefore, we

      continuously explore new technologies and

      read and study the work of other craftsmen.

We Share

We consider it our responsibility

  to perpetuate the craft of Software;

    therefore, we

      enlist apprentices to learn it and

      actively engage other craftsmen in dialogue and practice.

******************************************************************

[Paulo Köch]

Perfect! :)

Cheers,
Paulo Köch

[David Stanek]

I really like this. Great job!

--
Sent from my mobile device

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

[Rock Hymas]

I love it. One thing that feels awkward though is "to gain the trust of the businesses we serve". Can businesses be customers? Or to open it up even more, why not "to gain the trust of those we serve"? Or to make it more clean "to gain the trust of our customers"?
________________________________________
From: software_cr...@googlegroups.com [software_cr...@googlegroups.com] on behalf of Paulo Köch [paulo...@gmail.com]
Sent: Wednesday, April 22, 2009 4:36 PM
To: software_cr...@googlegroups.com
Subject: [SC] Re: The Software Craftsman's Ethic

[LudovicoVan]

On 22 Apr, 23:31, Doug Bradbury <d...@8thlight.com> wrote:
> Craftsmen,
>
> I've been working together with a few people on that list of
> principles / ethics that we were trying to hash out earlier on the
> list. What do you think of this both in form and content?

With all due respect, including to the energy and inventive that has
been invested into it, I'd have some severe criticism to this document
(in content, of course). If it is of interest, please let me know and
I will try some "counter-analysis".

-LV

[Doug Bradbury]

LV,

Please, share your analysis.

Doug

[Kaleb Pederson]

On Wednesday 22 April 2009 05:05:21 pm Rock Hymas wrote:
>
> I love it. One thing that feels awkward though is "to gain the trust of the businesses we serve". Can businesses be customers? Or to open it up even more, why not "to gain the trust of those we serve"? Or to make it more clean "to gain the trust of our customers"?

I agree.

I wonder if the viewpoint taken should be more explicit as well. For example, with "...to gain the trust of the businesses we serve," is our role that of a consultant or an employees to the business? Shortly thereafter we read, "we take our customer's [sic] problems as seriously as they do." But, if our viewpoint is that of a consultant, the business is the customer. [Note that we probably want customers' (apostraphe after the s).] As an employee, I suppose we could say the business is our customer but if the business does contracting, then who is really the customer?

And, "as seriously as they do?" Unfortunately, not every company is truly serious about the work so I'd rather say something more absolute -- "we take each customers' problems seriously," "we treat each customers' needs with devotion," etc.

That's it for now.

--Kaleb

[Olof Bjarnason]

I think this is a good start.

One observation to share:

We Share
We consider it our responsibility
to perpetuate the craft of Software;
therefore, we
enlist apprentices to learn it and
actively engage other craftsmen in dialogue and practice.

Something feels wrong with "to learn it" here:

"We consider it our responsibility to perpetuate the craft of Software

therefore we enlist apprentices to learn it."

"to learn it" - is there some other expression with more flow in it?

2009/4/23 Doug Bradbury <do...@8thlight.com>:

--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

[Jason Gorman]

My thoughts are summed up here:

http://parlezuml.com/blog/?postid=804

On Apr 23, 7:01 am, Olof Bjarnason <olof.bjarna...@gmail.com> wrote:
> I think this is a good start.
>
> One observation to share:
>
> We Share
> We consider it our responsibility
>   to perpetuate the craft of Software;
>     therefore, we
>       enlist apprentices to learn it and
>       actively engage other craftsmen in dialogue and practice.
>
> Something feels wrong with "to learn it" here:
>
> "We consider it our responsibility to perpetuate the craft of Software
> therefore we enlist apprentices to learn it."
>
> "to learn it" - is there some other expression with more flow in it?
>

> 2009/4/23 Doug Bradbury <d...@8thlight.com>:

>
>
>
>
>
> > Craftsmen,
> > I've been working together with a few people on that list of principles /
> > ethics that we were trying to hash out earlier on the list.  What do you
> > think of this both in form and content?
> > Doug
> > You might to prefer to view the doc on google:

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

> olofb.wordpress.com/tag/english- Hide quoted text -
>
> - Show quoted text -

[Olof Bjarnason]

Jason; when you blog about things discussed here, you hijack the discussion.

So I'm going to "steal it back" here. :)

I think what Jason is proposing (a "slogan") is something orthogonal
to the ethics statement of Doug.

We can have both! Of course, it is all the better if the slogan uses a
subset of the words from the ethics statement.

2009/4/23 Jason Gorman <goo...@parlezuml.com>:

--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

[Adewale Oshineye]

All of these manifestos, slogans and ethics are merely, to quote Chris
Matts, "placeholders for a conversation."
As long as we don't lose sight of that then we'll be fine.

2009/4/23 Jason Gorman <goo...@parlezuml.com>:

[Jason Gorman]

TBH, I think we're taking this all far too seriously. Do I complain
when people "hijack" my blog posts (or my slogan, come to that)?
There's no official software craftsmanship community, wiki, manifesto,
book/bible or commemorative dinner set. I felt the need to share my
feelings on this discussion with the people who read my blog. So I
did. I posted a link to the group in case anyone wanted to read it.
Which was thoughtful of me, don't you think? ;-)

Be under no illusion; I'm not proposing anything for anyone except
myself. That's my slogan for my personal take on software
craftsmanship. Maybe you find it useful. Maybe you don't. Maybe you'll
get a t-shirt printed. Maybe you won't. You're very welcome to use it
(unedited, of course.)

But please don't type up your ethics and post them on a web site and
say "these are the official ethics of a software craftsman" because
none of us has any more valid a claim on that territory than anyone
else.

Ta very much :-)

Jason Gorman
http://www.codemanship.com

[Olof Bjarnason]

2009/4/23 Jason Gorman <goo...@parlezuml.com>:

>
> TBH, I think we're taking this all far too seriously. Do I complain
> when people "hijack" my blog posts (or my slogan, come to that)?
> There's no official software craftsmanship community, wiki, manifesto,
> book/bible or commemorative dinner set. I felt the need to share my
> feelings on this discussion with the people who read my blog. So I
> did. I posted a link to the group in case anyone wanted to read it.
> Which was thoughtful of me, don't you think? ;-)
>
> Be under no illusion; I'm not proposing anything for anyone except
> myself. That's my slogan for my personal take on software
> craftsmanship. Maybe you find it useful. Maybe you don't. Maybe you'll
> get a t-shirt printed. Maybe you won't. You're very welcome to use it
> (unedited, of course.)
>
> But please don't type up your ethics and post them on a web site and
> say "these are the official ethics of a software craftsman" because
> none of us has any more valid a claim on that territory than anyone
> else.

Please do not be upset Jason :)

The reason I posted was that this mailing list's sole purpose is
discussing software craftsmanship.

So while I agree in much of what you state above (there is no
"official" anywhere near), I think the discussion should be here
primarily, and on blogs secondarily. Cross-posting, sure, but it
should at least be here.

--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

[LudovicoVan]

On 23 Apr, 03:49, Doug Bradbury <d...@8thlight.com> wrote:
> LV,
>
> Please, share your analysis.

Thank you, appreciated. Of course this "analysis" won't be completely
neutral, as I have my opinions on these matters. Anyway, let's see.
Here is a first round:

> ********* The Software Craftsman's Ethic *******************

> We Care
> We consider it our responsibility
> to gain the trust of the businesses we serve;
> therefore, we
> take our customer's problems as seriously as they do and
> stake our reputation on the quality of the work we produce.

Right, a very good notion is that we work to be trusted, as a doctor
(this reminds consultancy). As to "how" we do it, I'd rather mention
things like absolute honesty, reliability, etc. That we produce
quality code instead I find inappropriate: the focus is the customer,
I am absolutely convinced of this, but by this very fact, quality in
itself is not a priority: requirements, to me, should be the reference
point (quality is, in fact, a function of requirements).

> We Practice
> We consider it our responsibility
> to write code that is defect-free, proven, readable, understandable
> and malleable;
> therefore, we
> follow our chosen practices meticulously even under pressure and
> practice our techniques regularly.

Nitpicks: proven is implied by defect-free (this one, I guess, we
could discuss for long..); understandable is implied by readable;
malleable is mantainable (and, IMO, could too be implied by readable,
although this is a personal and "radical" approach).

As to how we do it, I agree with following the "best" practices, but
would specify that "best" here is in accordance (and sub-ordinem!
Maybe this too is a bit "radical"?) to given requirements. (To expand
a tiny bit: I am saying that the best of our knowledge is in the
problem-solving...)

That we practice our techniques I would put in the following point, on
learning.

> We Learn
> We consider it our responsibility
> to hone our craft in pursuit of mastery;
> therefore, we
> continuously explore new technologies and
> read and study the work of other craftsmen.

Agreed. I would just include "practice", from previous point, to
substitue the mention to "technologies", which sounds a bit narrow in
perspective. To broaden furtherly, I would also avoid mentioning "work
of other craftsmen", and resolve for a broad balance between study and
practice.

(Slightly more "radical", and I mention it as a sketch of a proposal,
is to specify that craftsmen consider this learning practice and the
work practice one and the same thing, in theory and... in practice.)

> We Share
> We consider it our responsibility
> to perpetuate the craft of Software;
> therefore, we
> enlist apprentices to learn it and
> actively engage other craftsmen in dialogue and practice.

Agreed. I just find it a bit restrictive: for instance all the blog
posting some of us are doing about what this thing is? I.e., won't we
also be sharing our notions and experience with the general public
(technical, but not only: e.g. just think management)?

-LV

[LudovicoVan]

On 23 Apr, 07:53, Jason Gorman <goo...@parlezuml.com> wrote:
> My thoughts are summed up here:
>
> http://parlezuml.com/blog/?postid=804

Hi Jason,

I have read you blog post. I find your position debatable: IMHO,
communication is important, but the great potential here is in getting
out of that very isolation, by building together a common identity and
a specific reference discipline.

-LV

[Raoul Duke]

>   to write code that is defect-free, proven

hmmm. i continue to not understand how people can claim such things. i
mean, i can see it as "hey, we're saying that we would like to do our
best" but isn't it the fact that any non-dirt-simple program is
provably not remotely realistically provably defect-free?

sincerely.

[LudovicoVan]

Agreed that a plain "defect-free" can't... work. Anyway, I believe we
have to commit to something "measurable". What about: we write code
within _guaranteed bounds of correctness_ (there may be many methods
for this, including "light" ones; maybe even down to the "to our
best"?).

-LV

[Raoul Duke]

> Agreed that a plain "defect-free" can't... work.

things like "we strive to write defect-free code" is ok to me, it says
there is a reach which sure might go beyond our grasp but what else is
a reach for kinda thing.

which, depending on how one reads things as they are now, might be
what it is saying :-) so maybe i'm just worried that the wording could
be read (by people like me?) as over-promising.

and, ja, i agree that metrics/measurement are required tools for
keeping such promises.

sincerely.

[Robert Williams]

Doug,

I very much like the form of this, and most of the content.

But what would agreeing that I strive to write defect-free code
actually mean, practically? What would I need to do differently than
just banging out some code, running through it once, and deciding it
looks good to me? I'd rather say something about code that has been
rigorously tested.

Also, I don't have "gain[ing] the trust of the businesses" I work with
as an explicit goal, personally. I do a good job because "I am what I
do" and I'm a professional. It's important to write good code because
software is important to my employer/client/customer, and developing
that software is my responsibility (seeing how I'm paid to do it).

Robert Williams
http://www.passionatesoftware.com

[Dave Hoover]

On Thu, Apr 23, 2009 at 9:02 PM, Robert Williams <rober...@gmail.com> wrote:
>
> But what would agreeing that I strive to write defect-free code
> actually mean, practically?  What would I need to do differently than
> just banging out some code, running through it once, and deciding it
> looks good to me?  I'd rather say something about code that has been
> rigorously tested.

It sounds like for you that striving to write defect-free code means
rigorously testing it. I think that these Ethics are not trying to
prescribe too much, and instead leave room for the different
approaches to accomplish what the ethics propose. I would assume that
most of us would use an approach like Extreme Programming to
accomplish a lot of what is proposed in the Practice ethic, but that
is not the only way.

[Paul Pagel]

On Apr 23, 2009, at 8:39 PM, Raoul Duke wrote:

>
>> Agreed that a plain "defect-free" can't... work.

I disagree. The code we release should be defect-free. That doesn't
mean it is perfect every step of the way, but we treat every release
as an end and not just a means. There are no known defects in our
system. From experience, I know this can work.

I recently posted a blog about the ethics of software defects here:
http://blog.8thlight.com/articles/2009/4/8/ethical-approach-to-software-bugs

[eco...@gmail.com]

I have to agree with Paul here.

Nobody is saying that 0 bugs is necessarily an easy thing to do,
specially if you face some legacy code that has been dumped on you.
Because it is not easy it doesn't mean that it is not something that
we have to target, and in the case of a new code base have to do.

This sounds to me like saying, because TDD (and with TDD I mean test
first) is difficult we don't do it! What about pairing? Too difficult
to? Should we drop that one too?

If what we pretend is to raise the bar, and make things better every
day, step by step, we need to embrace practices, which we know that
are good, even if they sound scary or very difficult to achieve. I see
that as the only way of really being able to become better at what we
do; setting targets that are high and work towards them, slowly, step
by step...

Enrique

>
>
> >

[Olof Bjarnason]

2009/4/24 <eco...@gmail.com>:

I think there might be disagreement as to what "0 bugs" mean.

I think Enrique and Paul is talking about _known_ bugs, as in "backlog items".

I think Raoul is talking about _bugs in general_.

So both are right - there just needs to be a clarification in nomenclature.

I agree with Raoul on the general issue. Provably* bug-free software
is prohibitively expensive and not practically possible for anything
but thoroughly/analytically understood things like numeric libraries
of mathematical functions, (the precision of sin and cos in the
standard math libraries, for example).

* A proof to me is a mathematical one, as in deduction/induction and
the like. Examples of correct behaviour (as green unit tests are) make
it plausible a piece of software is correct- plausible enough to make
me believe in the statements of "0 known bugs" from Enrique and Paul.

>
> Enrique
>
>>
>>
>> >
>
>
> >
>



--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

[Francesco Rizzi]

Lots of good opinions here, but in order to form my own, I got to ask:
is the Manifesto meant to specify what we strive for, or what we actually do on a daily basis ?

'cause, you know.. in theory, theory and practice are the same, but in practice not so much.

So, I strive to produce defect-free products, but the harsh reality is that it might be impossible (for one, the end-user, the customer, the manager, the developer, everyone else and their mother have different definition of what a defect is...)

F.O.R.

[LudovicoVan]

On 24 Apr, 15:55, Paul Pagel <paulwpa...@gmail.com> wrote:
> On Apr 23, 2009, at 8:39 PM, Raoul Duke wrote:
>
> >> Agreed that a plain "defect-free" can't... work.
>
> I disagree.  The code we release should be defect-free.  That doesn't  
> mean it is perfect every step of the way, but we treat every release  
> as an end and not just a means.  There are no known defects in our  
> system.  From experience, I know this can work.

Defect-free and no known defects is not the same thing. A plain,
unqualified defect-free can't work because, apart from few specific
exceptions, proving (in the math sense) the correctness of a software
system is simply unfeasible. This said, your approach is mine as well,
and yes it works, but it's more marketing to the cluelessness of the
whole environment than anything technical.

I think we have to commit to something that makes technical sense, not
to the usual slogans or good intentions ("we strive to do this and
that"). As Robert Williams puts it earlier, what does it mean
*practically* to build "defect free software"? I won't try any easy
answer (that deserves a whole thread on its own, as well as there are
many ways and levels to it). Rather the point, as usual, is that we
need *not* prescribe what exactly one has to commit to: what we'd
prescribe is that there *is* such a commitment, the "guaranteed
bounds" (as I've put it, because math supports that; surely not the
only possible characterisation).

For instance: saying that "there are no known defects in our
system" (I suppose we mean known or knowable to the customer) is in
fact a way to commit to a specific level of reliability, but... would
you be ready to put that on a contract?

-LV

[J. B. Rainsberger]

I'd like to work in here the notion that we consider it our
responsibility to drive down the marginal cost of a feature, or at
least, to let the cost of a feature depend primarily on the complexity
of the feature, and not on the state of the design. Let me propose
this extra stanza.

We Economize

We consider it our responsibility

to keep the cost of every feature reasonable;
therefore, we
build only what we need to deliver the current feature and
design in a way that prepares us for any feature you might choose next

I don't know whether that's too agile-sounding and therefore moves
away from the general craftsmanship message, but it points to our
commitment to supporting our customer and his business.
--
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

[Esko Luontola]

> We Practice

> We consider it our responsibility

> to write code that is defect-free, proven, readable, understandable and malleable;
> therefore, we
> follow our chosen practices meticulously even under pressure and
> practice our techniques regularly.

I would like to merge that with the though "we have high standards for
what we consider to be high quality, and we follow our standards
rigorously even under pressure."

[Peter Jaros]

On Fri, Apr 24, 2009 at 8:04 PM, LudovicoVan <ju...@diegidio.name> wrote:
>
> Defect-free and no known defects is not the same thing. A plain,
> unqualified defect-free can't work because, apart from few specific
> exceptions, proving (in the math sense) the correctness of a software
> system is simply unfeasible. This said, your approach is mine as well,
> and yes it works, but it's more marketing to the cluelessness of the
> whole environment than anything technical.

The Netscape people coined a phrase for this a long time back. When a
product had no known defects, they said it had "zarro boogs".

http://en.wikipedia.org/wiki/Zarro_boogs#Zarro_Boogs

Peter

[Jason Gorman]

I think this a great example of what I'm talking about.

When I said "We practice", I meant "We take time regularly to do
coding exercises just for the sake of it, specifically to build our
skills". I see that as the distinguishing factor between craftsmanship
and every other quality-driven or professionalism-driven movement
that's come before this. The danger is in promoting a set of ethics
that a CMMi auditor would happily sign up to, because if they agreed
with it then surely we're not saying anything new. I know that your
average CMMi practitioner doesn't get up in the morning and do a few
laps of TDD before he has his shower.

If we fail to keep this distinction - er, well - distinct then I think
we're losing the whole essence of this potentially wonderful
progression. Developers taking time in their daily/weekly routine to
code for the sake of it, and specically to focus on quality-driven
practices and stretch themselves in those skills, is the step forward
I've been looking for all these years. Programming is a practical
skill, like riding a bike or playing the trombone. You cannot learn it
from books or from seminars or on a 3-day "Certified Trombone Master"
course. You can only learn it by doing it. A lot.

So I vote + several million for keeping "We practice" distinct and in
bold with flashing lights around it :-)

Jason Gorman
Certified Juggler
www.codemanship.com

[Olof Bjarnason]

2009/4/25 Jason Gorman <goo...@parlezuml.com>:

>
> I think this a great example of what I'm talking about.
>
> When I said "We practice", I meant "We take time regularly to do
> coding exercises just for the sake of it, specifically to build our
> skills". I see that as the distinguishing factor between craftsmanship
> and every other quality-driven or professionalism-driven movement
> that's come before this. The danger is in promoting a set of ethics
> that a CMMi auditor would happily sign up to, because if they agreed
> with it then surely we're not saying anything new. I know that your
> average CMMi practitioner doesn't get up in the morning and do a few
> laps of TDD before he has his shower.
>
> If we fail to keep this distinction - er, well - distinct then I think
> we're losing the whole essence of this potentially wonderful
> progression. Developers taking time in their daily/weekly routine to
> code for the sake of it, and specically to focus on quality-driven
> practices and stretch themselves in those skills, is the step forward
> I've been looking for all these years. Programming is a practical
> skill, like riding a bike or playing the trombone. You cannot learn it
> from books or from seminars or on a 3-day "Certified Trombone Master"
> course. You can only learn it by doing it. A lot.
>
> So I vote + several million for keeping "We practice" distinct and in
> bold with flashing lights around it :-)

+1

>
> Jason Gorman
> Certified Juggler
> www.codemanship.com
>
> On Apr 25, 4:16 pm, Esko Luontola <esko.luont...@gmail.com> wrote:
>> > We Practice
>> > We consider it our responsibility
>> >  to write code that is defect-free, proven, readable, understandable and malleable;
>> >    therefore, we
>> >      follow our chosen practices meticulously even under pressure and
>> >      practice our techniques regularly.
>>
>> I would like to merge that with the though "we have high standards for
>> what we consider to be high quality, and we follow our standards
>> rigorously even under pressure."
> >
>

--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

[Paul Pagel]

Great point. I meant known defects, not defect free.

[Robert Williams]

I didn't actually say, or mean to imply, anything about TDD, BDD, unit
tests, automated acceptance tests, etc. "Rigorously tested" could be
accomplished many ways; I don't think it's too prescriptive. I'm not
sure how else we could produce code with no known defects than by
testing it (other than mathematical proof in a few cases).

My concern is similar to what I think Jason Gorman's is - I want a
code of ethics that clearly distinguishes "us" from "them", so to
speak. In this particular example, I want something that clearly
distinguishes developers who actually *do* something to ensure/prove
their code has no known defects, from someone whose approach to
"striving to write defect-free code" means "it compiles and looks good
to me."

Have you ever met a developer, however sloppy, that wouldn't say he
wants to produce defect-free software?

When the Council of Nicea met to deal with Arianism, they started with
the Apostle's Creed (which they all could agree to) and added
distinctives until the Arians could no longer agree. That's how the
Nicene Creed came into being (more or less). They were searching for
language that would make the existing divisions clear.

Similarly, I think there's an existing division of attitudes toward
software quality, and I'd like a code of ethics to make this existing
division clear.

Robert

[Robert Williams]

I just read Jason's blog and I may have completely misunderstood him,
so my apologies if that's the case.

Robert

[Esko Luontola]

I think that it would be better to think first that what are the
actions of craftsmen, that make them different from other developers.
There is no point in stating things that are so generic and lame that
everybody agrees on them. After all, we want to make a distinction
between craftsmen and the others.

Only after that we can think about how to say it poetically (like the
manifesto and this proposed ethics list), if there is some value in
it. And even then, our acceptance criteria for the poetic version
should be that it expresses all the intent of the craftsmen's
distinctive actions.

Here are some that come to my mind:

- To make the project progress faster, we increase our quality instead
of writing sloppy code. We believe that high quality code makes it
possible to make changes faster.

- If our manager/customer tells us to stop wasting time in practices,
that we have determined to be necessary to maintain high quality, we
will not stop those practices. We cheat our boss and do it anyways, or
we will not work for him. It's the same as doctors/surgeons will not
stop washing their hands. Doing so would be unprofessional.

- We do not believe that the quality of all systems will inevitably
deteriorate over time, so that it needs to be rewritten after 5 years.
We work so that the quality of the system stays the same or gets
higher over the years. We write systems that are maintainable even
after 10, 20 or more years.

- Legacy code is code without tests. We do not write legacy code which
will be difficult for others to change when we have gone.

- We are all the time trying to learn new things by keeping up to date
what is happening in the professional community. We read news,
articles, blogs, forums and others about the bleeding edge and stay in
contact with other professionals. We will read, learn and practice new
things even if nobody will pay for it. We will do it on our own free
time, because we are proud of our craft, we want to become even better
in it and we like learning new things.

[Robert Hanson]

Late to the conversation. Here is my take on the original document.

> We Care

> We consider it our responsibility

> to gain the trust of the businesses we serve;
> therefore, we
> take our customer's problems as seriously as they do and
> stake our reputation on the quality of the work we produce.

Trust is an end not a means, and you can not make someone trust you.

As a craftsman it is my job to understand the problem, not to take it seriously.

> We Practice
> We consider it our responsibility
> to write code that is defect-free, proven, readable, understandable and malleable;
> therefore, we
> follow our chosen practices meticulously even under pressure and
> practice our techniques regularly.

Defect free is impossible unless the software is trivial or you are lucky.

You can't write proven code, it is time that proves it.

One man's defect is another man's feature. Is a defect an undesirable
behavior, a failure to meet a requirement, or an unexpected program
termination?

> We Learn

> We consider it our responsibility

> to hone our craft in pursuit of mastery;
> therefore, we
> continuously explore new technologies and
> read and study the work of other craftsmen.

Do you mean new technologies or new techniques?

> We Share

> We consider it our responsibility

> to perpetuate the craft of Software;
> therefore, we
> enlist apprentices to learn it and
> actively engage other craftsmen in dialogue and practice.

Having an apprentice is not a sign of craftsmanship.

Teaching is not a sign of craftsmanship.

Consistency is a sign of craftsmanshup.

Deliberate design is a sign of crafsmanship.

Reliability is a sign of craftsmanship.

- Rob

[Robert Hanson]

On Mon, Apr 27, 2009 at 8:49 AM, Esko Luontola wrote:
> We believe that high quality code makes it possible to make changes faster.

+1

> - If our manager/customer tells us to stop wasting time in practices,
> that we have determined to be necessary to maintain high quality, we
> will not stop those practices.

-1
I kinda agree, but don't think it should be included.

> - We do not believe that the quality of all systems will inevitably
> deteriorate over time

-1
Systems don't deteriorate by themselves. They are enhanced sloppily,
outlive their usefulness, or outlive their platform.

I prefer "reliable", without a time limit.

> - Legacy code is code without tests. We do not write legacy code which
> will be difficult for others to change when we have gone.

-1
Too specific. Tests do not imply readability, and not all tests can be
automated. Sometimes documentation is needed.

> - We are all the time trying to learn new...We will do it on our own free
> time, because we are proud of our craft...and we like learning new things.

+1

I would also like to add:

- We mean to develop software consistently and purposefully. Our software
is designed intentionally, drawing on our experience, as opposed to
designing software by accident.

- We develop reliable software. By reliable, we mean that we have taken steps
to ensure that the software is resistant to failure and defects. We employ
our knowledge of reliable design and testing to achieve this.

- We develop maintainable software. By maintainable, we mean that our
software is structured logically so that it may be easily read and extended
by other craftsman, avoiding obfuscation and undue complexity. We
employ our knowledge of patterns and practical experience to achieve this.

- As Software Craftsman we differentiate ourselves from Software Academics in
that we are practitioners first, teachers second. The Craft must be
practiced in order to master it, and we acknowledge that no about of
schooling can replace real world experience.

- As Software Craftsman we differentiate ourselves from initiates and
apprentices in that we have a history of developing masterful software.
Although others may strive to be consistent, or to deliver maintainable
software, as Software Craftsman we have already acheived this.

Rob

[Eric Smith]

Just want to second Paul's point.  Not only should there be no known defects - in my opinion keeping your bug backlog at zero is the only realistic way to deliver software fast, otherwise the payback of the bugs eventually eats all your time.

Michael Features defines legacy as code without tests - which is fine for him, and not wrong, but I would define it as "code where feature development must coexist simultaneously with bug fixing".  If you don't start features until your bug list is at 0, you can recreate the feeling of a greenfield environment.  Having worked in non-craftsman environments, where some defects will just never ever be fixed cause they're not important, there is no other way to work and create products worthy of craftsmen.

Eric

[Adewale Oshineye]

2009/4/27 Eric Smith <payto...@gmail.com>:

> Just want to second Paul's point.  Not only should there be no known defects
> - in my opinion keeping your bug backlog at zero is the only realistic way
> to deliver software fast, otherwise the payback of the bugs eventually eats
> all your time.
> Michael Features defines legacy as code without tests - which is fine for
> him, and not wrong, but I would define it as "code where feature development
> must coexist simultaneously with bug fixing".  If you don't start features
> until your bug list is at 0, you can recreate the feeling of a greenfield
> environment.  Having worked in non-craftsman environments, where some
> defects will just never ever be fixed cause they're not important, there is
> no other way to work and create products worthy of craftsmen.
> Eric

As the complexity and the age of your system increases doesn't the
(opportunity) cost of maintaining zero bugs increase accordingly?
If you have bugs in systems or tools that you depend upon do you
include those in your bug count? What do you have to change or give up
in order to stay at zero bugs?

[Robert Hanson]

On Mon, Apr 27, 2009 at 11:49 AM, Adewale Oshineye wrote:
> If you have bugs in systems or tools that you depend upon do you
> include those in your bug count? What do you have to change or give up
> in order to stay at zero bugs?

What if you rely on the behavior of the bugs and can't fix them?

The Java language has a lot of known bugs that can't be fixed because
it will break existing code.

I don't believe that can be absolutes. You can't commit to doing
anything other than what makes the most sense based on your
experience.

Rob

[Eric Smith]

Which is why you need to stay at 0 bugs in the early stages.  What we've done on our largest customer is the following:

* No stories can start until bug list is at 0.

* Fix bugs - then take story. 

* Don't worry about anything that isn't an immediate production issue until you finish the story. 

* Submit story - check bug list.

* Repeat.

This works most of the time.  Naturally there are occasional "explosions" -> QA hits the system in a new way, a new set of users come on line, a big feature goes on line, and these become difficult to deal with.  That's why we get the big bucks.  The important think to keep in mind is when these explosions happen when the system started with 0 known defects there's a lot less to deal with.  You asked what I give up - I give up having to manage defects, manage expectations because of defects.  I give up the churn that defects cause, and in exchange I get to do more feature development.

A 0 known defects policy is like TDD is to a lot of people.  Instinctively it sounds unmanageable to write two sets of code, but in fact you move faster.  0 known defects lets you work in a near-greenfield environment.  In the interest of full disclosure - this project at times didn't have a 0 known defects policy, and we were just spending so much time in churn that we took the poison pill, and fixed all the defects.  Customer satisfaction and velocity immediately increased.  It was painful, but nobody said this was easy.

Eric

** Oh I probably wouldn't count a bug in a non-customer facing system as a bug, but that's just me.

[Carl Hume]

Hi Eric,

On Mon, Apr 27, 2009 at 5:29 PM, Eric Smith <payto...@gmail.com> wrote:

In the interest of full disclosure - this project at times didn't have a 0 known defects policy, and we were just spending so much time in churn that we took the poison pill, and fixed all the defects.  Customer satisfaction and velocity immediately increased.  It was painful, but nobody said this was easy.

How big was the defect backlog?  How long did it take to get to 0?

 

Cheers!

Carl

 

[Jason Gorman]

So I feel I should interject at this point.

Firstly, the slogan I proposed originally was deliberately intended to
leave the details to the imagination of the individual software
craftsman. Any elaboration on "We care. We learn. We PRACTICE. We
share." is a personal journey as far as I'm concerned, and doesn't
necessarily reflect my own views or beliefs, even if I were able to
accurately articulate them, which I'm not.

I feel rather unhappy about us all borrowing the slogan and bolting on
extra detail, which effectively defeats my original goal. I think it
means we've missed the point somewhat :-)

People are also still getting very bogged down in the language.
"Craftsman", "Artisan", "Master", "Apprentice" etc etc. I fear this
continued navel gazing might be redundant and, ultimately, our
undoing. People are beginning to talk!

The bottom line is this: I know what I mean. And you know what you
mean. And when me and you sit down in front of the same piece of code
and see what each of us thinks is the right thing to do, it'll become
clear if we're agreeing or not.

To that end, I'm proposing a combination of three proposals that I've
made so far:

1. We adopt a symbol as the name for what we're doing and stop talking
about "craftsmanship". I propose the "okay" sign made with the
fingers.
2. Around the symbol should be the slogan "We care. We learn. We
PRACTICE. We share." Practice is our USP, so it should be highlighted
in some way.
3. Our movement only needs one rule: The first rule of software
craftsmanship is that you do not talk about software craftsmanship

Beyond that, everyone can find their own path to mastery.
Apprenticeships, peer group learning and assessments, alien brain
implants and so on. If it seems to be working, then it probably does.

Of course, I'm only partially joking, and you're all free to do as you
please (and that's my point, I think). I personally plan to adopt that
proposal, though. It'll look cool on my business cards, I reckon!

You may now start throwing the furniture around.

Jason Gorman
www.codemanship.com

On Apr 28, 12:11 pm, Carl Hume <carl.h...@gmail.com> wrote:
> Hi Eric,
>

[Eric Smith]

Hi Carl,

If memory serves we had somewhere in the neighborhood of 15 or so defects, maybe a few more.  Took about 8 working days - but I'm going off memory.  Of course this is a very small number ( the last project I worked on had over 15,000 entries in its defect tracking system) but that's because we treated any defect severely even before adopting the ethic. It was the realization we were getting a drain on our velocity from the constantly handling defects that drove us to squash it.

Mind you the system I'm using for reference now has 7 or 8 websites which interact with several third party systems.  It's not a million +, but its in the hundreds of thousands of lines of code.  

Eric

[Robert Hanson]

On Tue, Apr 28, 2009 at 8:36 PM, Jason Gorman wrote:
> You may now start throwing the furniture around.

Will do.

> effectively defeats my original goal. I think it means we've missed the point somewhat :-)

I don't believe it was entirely clear as the what the goal was other
than defining an ethic statement. And I think there were problems
with what you had.

> 1. We adopt a symbol as the name for what we're doing and stop talking
> about "craftsmanship". I propose the "okay" sign made with the fingers.

Uh... please no.

> 2. Around the symbol should be the slogan "We care. We learn. We
> PRACTICE. We share.

I can agree with that. I just didn't agree with your elaboration in
the original piece.

> People are also still getting very bogged down in the language.
> "Craftsman", "Artisan", "Master", "Apprentice" etc etc.

I think names are important. I think Craftsman is more appropriate
than Artisan. And the other two are merely levels, something which is
very hard to define with any measure of success.

> Beyond that, everyone can find their own path to mastery.

I think I came to this list looking for the path, or at least potential paths.

> Of course, I'm only partially joking, and you're all free to do as you please

I was kinda hoping for more than that. I was looking for a cool club
logo that I could put on the back of a biker's jacket, or maybe a
declaration of who we are and why we are doing this.

Rob

[Jason Gorman]

It's not my goal to define a shared set of ethics. Far from it. Again,
I think perhaps people might be misinterpreting what I'm saying. And
that's my whole point, really. People WILL misinterpret and project
their own unique and complex internal prejudices and beliefs. That's
inevitable. It's happening already :-)

I do feel, from the general direction the discussions are going in,
that I'm probably leaning in quite a different direction to the vocal
majority in this community. Maybe I should stop referring to what I
believe in as "software craftsmanship", rather than try and argue with
folk who want to call what they believe in "software craftsmanship"
that I've got it right and they've got it wrong.

Jason Gorman
www.codemanship.com

[Brian Marick]

On Apr 28, 2009, at 7:36 PM, Jason Gorman wrote:
> 1. We adopt a symbol as the name for what we're doing and stop talking
> about "craftsmanship". I propose the "okay" sign made with the
> fingers.

Best check first whether that symbol doesn't have a conflicting
meaning in, say, Indian or Chinese culture.

>
> 2. Around the symbol should be the slogan "We care. We learn. We
> PRACTICE. We share." Practice is our USP, so it should be highlighted
> in some way.

+1

>
> 3. Our movement only needs one rule: The first rule of software
> craftsmanship is that you do not talk about software craftsmanship

Naw.

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick