At the summit that 8th Light hosted in December, we kicked around the
idea of creating a charter or manifesto for software craftsmanship.
Not everyone agreed that such a document was necessary or valuable. I
like having my values written down and I have continued to think about
such a document.
I decided to frame the value in terms of how they are different from
the values in the agile manifesto while not dismissing that manifesto
altogether. I've come up with four things that we value more that we
value the left side of the manifesto. Here it is:
******************************************************************
As aspiring Software Craftsmen we are raising the bar of professional
software development by practicing it and helping others learn the
craft. Through this work we have come to value:
well-crafted software over working software over comprehensive
documentation
steadily adding value over responding to change over following a
plan
a community of craftspeople over individuals and interactions over
processes and tools
impressing our customer over customer collaboration over contract
negotiation
That is, while we still value the items in the middle over the items on
the right, we value the items on the left even more.
********************************************************************
I have also divided the value statement we wrote at the summit into
these four categories and called them 'principles.'
well-crafted software
... We believe the code is also an end, not just a means.
... We follow a set of practices and disciplines that ensure quality
in our work
steady value
... We say no to prevent doing harm to our craft
community
... we live and work in a community with other craftsmen
... we will help other craftsmen in their journey
... We can point to the people who influenced us and who we influenced
impressing
... We are proud of our work and the manner of our work
... We take responsibility for the code we write
... We are proud of our portfolio of successful projects
**************************************************************************
So I'm posting to the list, not because I think we can reach any
consensus on the tricky medium of email, but because I'd like to see
these values tested a bit... pushed and prodded in the hopes of making
them stronger.
For example, I'm not thrilled with the phrase "impressing our
customer," but I haven't been able to some up with something that
captures how we create solutions that are better than our customers
could have imagined. How we take responsibility for innovation, our
code and our practices.
Have at it.,
Doug Bradbury
How about a furniture example? If one of the 4 legs of a chair was
shorter than the others and the chair rocked horribly when you sat in
it, would you call it well crafted? It could be beautifully finished
and polished, but it doesn't work right so it can't be well-crafted.
Something that is well crafted is both functional and beautiful.
Something that is beautiful but not functional I would call art but
not craft.
Saying the software is well crafted is saying that it works well and
is easy to read / understand / maintain.
Doug
On Feb 10, 2009, at 11:23 AM, Olof Bjarnason wrote:
I don't know. When I buy well crafted furniture, I expect that it
looks good, is functional, and will retain both attributes for
generations. Whereas when I buy furniture from Ikea, I'd expect it to
work but I know it's not going to look great and I'll need to replace
it in a few years.
Micah
It may be that the Agile Left Side is intended to be a superset of its
corresponding Right Side as well; I've just always assumed that the
idea is that a choice may be made between the two sides at some point,
and in that case, Agile would choose Left and reject Right (for that
specific point, not generally discounting the right-side ideas, of
course).
I hate to nitpick, because these are exactly the principles I want my
software career to follow, but it seems to be a slightly confusing
point. Would there be as much power of meaning if a word like
"beyond" was used in place of "over" (to separate the New Left Side
from the Agile Left Side), or am I looking at this in a different way
than most?
- Colin
--
Colin Jones
Thoughts?
Doug
On Feb 10, 2009, at 4:48 PM, Robert Martin wrote:
> exceeding expectations
As aspiring Software Craftsman we are raising the bar of profressional software
development by practicing it and helping others to learn the craft. Through
this work we have come to value:
1) well-crafted software
over working software
over comprehensive documentation
2) steadily adding value
over responding to change
over following a plan
3) a community of craftsmen
over individuals and interactions
over processes and tools
4) exceeding expectations
over customer collaboration
over contract negotiation
That is, while we still value the items in the middle over the items on the
right, we value the items on the left even more.
Looking on the principles:
1) We believe well-crafted code is not a destination, it is a point of origin.
2) We follow a set of practices and disciplines that ensure quality and pride
in our work.
3) We decline when we would do any harm to our craft.
4) Through well-crafted software we enable ourselves to not only deliver a
useful system today, but additionally to be able to deliver value to
tomorrow's business.
5) We live and work in a community with other craftsmen.
6) We will help other craftsmen in their journey to mastery.
7) We can point to the people who influenced us and who we influenced on our
own journey.
8) We are proud of our professional work and the manner of it.
9) We take responsibility for the code we write.
10) We are proud of our portfolio of successful projects.
11) We are continuously improving our own skills and practices to exceed
previous successes.
I found Point 5 to be a bit difficult to note. What I would like to express, is
the Cooperative Game principle from Cockburn: A successful project has two
goals: deliver a system and prepare for the next round - this might be
adapting, extending or operating the system. Personally I also tend to add a
third item on the steadily adding value part. May be some combination of adding
value to the software as well as adding value to one personal skills, but this
would be the same as point 11.
Kind regards
Markus Gärtner
I've been describing the craftsmanship movement as a post-agile enhancement, rather than a replacement.
Pardon the late entry into the conversation.
I agree, in principle, that craftsmanship, as I believe we are trying
to define it, evolves from agile, but I don't see it as a linear
evolution. I find this mapping to be constraining, and I can easily
see it being poorly received by admirers of the manifesto as "we're
better than agile", which I don't think is the message. I can't tell
you what I think the message *is* just yet, but I don't think we want
to set off a pissing contest.
Second, even if we take for granted that the new left side is *it*, #3
presents another challenge for me. "Individuals and interactions," as
I see it, is about teams of people including *but not limited to*
developers. "a community of craftsmen" kinda leaves out the
non-technical stakeholders. Not that they can't be craftsmen in their
own right, but I don't think we're really talking about them when we
talk about "a community of craftsmen."
Thoughts?
(from mobile)
I personally am not comfortable saying that Craftsmanship is better than Agile
Let's test this statement. It is saying you may be a craftsman if you:
- use tools and process rather than interact with individuals
- prefer comprehensive documentation over working software
- hold to a contract rather than collaborate with the customer
- follow the plan rather than respond to change
I can't imagine calling such a person a craftsman, in any craft.
Micah
Yes. This has been on my mind for quite a while. It was topic I
considered discussing at the Software Craftsmanship Summit.
What's needed is a community where craftsmen vouch for other
craftsmen. A certification will not tell you that someone is a
craftsman. But if recognized master craftsmen vouch for a particular
developer, you can be quite confident that she is a craftsmen.
The dynamics become interesting. For instance, vouching for someone
as a craftsman is not small matter. By vouching for Joe, you are
putting your reputation at stake that Joe is really a craftsmen. If
it turns out that Joe is a hacker, your vouch looses significance and
your reputation is tarnished.
Anyhow, a social networking web site seems like the best medium for
such a community. I have many ideas for how such a site should work.
Micah
Anyhow, a social networking web site seems like the best medium for
such a community. I have many ideas for how such a site should work.
On Feb 11, 2009, at 15:00 , Eric Meyer wrote:I personally am not comfortable saying that Craftsmanship is better than Agile
Several folks have expressed this opinion. At first I nodded in agreement. Then I thought: "If it's not better, why are we bothering?" Honestly, don't we think that raising the craftsmanship bar is a better way to do agile, just like agile was a better way to manage software projects?
> To me, the idea of being a craftsman is most simply described as
> taking pride in my work and caring for the job I do.
That, plus the notion of "lineage" (or "heritage") would cover it for
me. I prefer "lineage" or "heritage" to "school" because it shifts the
emphasis to people and to building on history. I also hope it
suppresses a problem "schools" have, which is that people *love* to
pigeonhole other people, to assign them to a school, even if (perhaps
especially if) those other people don't care to be pigeonholed.
I think if we concentrated more on heritage, we'd get more
introductions like this:
Although this is a book about RubyCocoa, I've snuck in
bits and pieces of a philosophy and pragmatics of
application design. It's a style I've learned from
people like Kent Beck, Ward Cunningham, Carl Erickson,
Michael Feathers, Martin Fowler, Richard P. Gabriel,
Andy Hunt, Ron Jeffries, Ralph Johnson, Joshua
Kerievsky, Yukihiro Matsumoto, Richard Stallman, Guy
Steele, Pragmatic Dave Thomas, and others. Without them,
this book would have been a lot less interesting to
write and---I hope---read.
-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
> What's needed is a community where craftsmen vouch for other
> craftsmen. A certification will not tell you that someone is a
> craftsman. But if recognized master craftsmen vouch for a particular
> developer, you can be quite confident that she is a craftsmen.
Laurent Bossavit and I started such a site a year or so back: http://wevouchfor.org/
Laurent was the brains behind it.
>
> On Feb 12, 2009, at 8:30 AM, Micah Martin wrote:
>
>> What's needed is a community where craftsmen vouch for other
>> craftsmen. A certification will not tell you that someone is a
>> craftsman. But if recognized master craftsmen vouch for a particular
>> developer, you can be quite confident that she is a craftsmen.
>
>
> Laurent Bossavit and I started such a site a year or so back: http://wevouchfor.org/
> Laurent was the brains behind it.
Something like http://workingwithrails.com/ could have been.
I've enjoyed reading all these messages, folks. You're very thoughtful
and innovative people. I can vouch for Brian Marick, at least!
--
Adam Williams
http://github.com/aiwilliams
I've made some edits to the document to incorporate some of the
feedback on the list.
http://groups.google.com/group/software_craftsmanship/web/the-new-left-side
Community of Craftspeople -> Community of Professionals
I believe that this correctly includes non-developer professionals.
impressing our customer -> Business Partnerships
The more I though about this, the more I liked it. Partnership
obviously builds on top of collaboration.
I also added four definitions to clarify the relationship between the
new left side on the old left side. Here they are
- Well crafted software works well, but also the code is easy to
read, understand and modify.
- We respond to changing requirements, but also keep the project
from spinning in circles.
- Individuals and interactions form a community of professionals
whose reputations are interdependent.
- We not only collaborate with our customers, but also partner with
them; they feel as though we are in the boat with them; we take their
needs as seriously as they do; they trust us with their problems.
Let me try to rephrase it while trying to incorporate some aspects I liked so far:
As aspiring Software Craftsman we are raising the bar of profressional software
development by practicing it and helping others to learn the craft. Through
this work we have come to value:
1) well-crafted software
over working software2) steadily adding value
over comprehensive documentation
over responding to change
over following a plan
3) a community of craftsmen
over individuals and interactions
over processes and tools
4) exceeding expectations
over customer collaboration
over contract negotiation
That is, while we still value the items in the middle over the items on the
right, we value the items on the left even more.
Looking on the principles:
1) We believe well-crafted code is not a destination, it is a point of origin.
2) We follow a set of practices and disciplines that ensure quality and pride
in our work.
3) We decline when we would do any harm to our craft.
4) Through well-crafted software we enable ourselves to not only deliver a
useful system today, but additionally to be able to deliver value to
tomorrow's business.
5) We live and work in a community with other craftsmen.
6) We will help other craftsmen in their journey to mastery.
7) We can point to the people who influenced us and who we influenced on our
own journey.
8) We are proud of our professional work and the manner of it.
9) We take responsibility for the code we write.
10) We are proud of our portfolio of successful projects.
11) We are continuously improving our own skills and practices to exceed
previous successes.
I found Point 5 to be a bit difficult to note. What I would like to express, is
the Cooperative Game principle from Cockburn: A successful project has two
goals: deliver a system and prepare for the next round - this might be
adapting, extending or operating the system. Personally I also tend to add a
third item on the steadily adding value part. May be some combination of adding
value to the software as well as adding value to one personal skills, but this
would be the same as point 11.
Kind regards
Markus Gärtner
http://www.praxis-his.com/sparkada/
not particularly agile, as i expect most people think of it?
I would agree to some extent, but I think of craftsmanship in any area as being the pursuit of quality in the production process, whereas I think of various agile practices as being the techniques one uses in this pursuit.
Derek
Agile is not dependent on waterfall is it?
I'm fairly sure that was deliberate, to prevent it being picked up by
management types and turned into a meaningless buzzword (as "agile"
has in many places).
Kerry
Bob said, "I think Craftsmanship is the name that Extreme Programming
should have had all along."
Then Bob said, "The stuff [of XP] that got stripped away as Scrum made
its way into the business community was the essence of writing code
well. It was this notion of Craftsmanship."
My only issue with these statements is that Software Craftsmanship is
more than writing code well. Writing code well is necessary to be a
Software Craftsman, but not sufficient.
> Software craftsmanship seems to be
> an extension/progression of the original XP values.
> Where as agile contains many of those principles, but builds onto it with
> good ideas (project management/ teams/etc.). If you follow this argument
> then, we are not moving away from or beyond agile, but agile built upon
> XP/craftsmanship the whole time. We are evolving what craftsmanship itself
> means, moving beyond XP.
I do not believe that Software Craftsmanship is an extension of the
original XP values, so I don't follow that argument. I agree that we
have been evolving what Software Craftsmanship itself means (by tying
it into XP and Agile) and this concerns me.
Software Craftsmanship (the book) was written in 2001. It references
the then newly formed Agile Alliance:
"The Agile Alliance offers a strong alternative to the traditional
software engineering way of doing software development. By rejecting
the process-driven approach, the Agile Methodologies focus attention
on the individuals in the software development team and the quality of
their interactions with their customers and users. In doing so, they
provide a good fit with software craftsmanship and another voice
warning about the hazards of the software engineering approach."
The book also references eXtreme Programming (remember when we
capitalized it like that?):
"eXtreme Programming works by paying attention to the craft of
software development, to what developers and customers do on a
minute-by-minute basis. Although initially this approach was seen as
controversial, a key factor in the acceptance of eXtreme Programming
by developers is that it fits the way that humans like to work. More
than anything else, it supports software development as a social
process. It takes what has been seen as a purely intellectual
challenge and transforms it into a conversation. Rather than reading
documents, developers talk to the users and one another, and they pair
up for producing all production code. eXtreme Programming is
interesting because it has practices in place for ensuring that the
people on the project work together as a team. By forcing developers
to communicate about the system they are building, eXtreme Programming
is re-creating a craft studio where everyone learns from each other."
That last sentence is enlightening to me. What I take away from these
connections from the book is that 1) both Agile and Software
Craftsmanship distinguish themselves from the Software Engineering
tradition, and 2) by following the XP practices you will eventually
find yourself with something resembling a "craft studio".
A lot of the wisdom represented by the XP practices is based on
recognizing that most software development is a craft, so it's not
surprising to me that both Software Craftsmanship and XP often end up
with overlapping ideals and practices. Yet that doesn't mean that
either of them built on each other. Furthermore, Software
Craftsmanship has many tenets that XP does not pay attention to (and
vice-versa). To take some examples from the book:
* Craftsmanship is the opposite of licensing
* Craftsmen sign their work
* Craftsmen prefer non-proprietary, open source tools
* Customers have long-term relationships with Craftsmen
* Master Craftsmen are responsible for passing on the craft
* Apprenticeship is more effective than training
Rather than trying to situate Software Craftsmanship in the context of
Agile or XP, I would prefer us to mine this book for it's core
concepts and discuss our experiences in trying to apply them.
Best,
Dave Hoover
//obtiva: Agility applied. Software delivered.
Bob said, "I think Craftsmanship is the name that Extreme Programming
should have had all along."
Then Bob said, "The stuff [of XP] that got stripped away as Scrum made
its way into the business community was the essence of writing code
well. It was this notion of Craftsmanship."
My only issue with these statements is that Software Craftsmanship is
more than writing code well. Writing code well is necessary to be a
Software Craftsman, but not sufficient.
> Software craftsmanship seems to be
> an extension/progression of the original XP values.
> Where as agile contains many of those principles, but builds onto it with
> good ideas (project management/ teams/etc.). If you follow this argument
> then, we are not moving away from or beyond agile, but agile built upon
> XP/craftsmanship the whole time. We are evolving what craftsmanship itself
> means, moving beyond XP.
I do not believe that Software Craftsmanship is an extension of the
So in order to look cool to our cross disciplinary friends we should
rebrand XP to something that doesn't summarize it succintly?
I don't don't personally own the XP book but if memory serves me right
the rationale for calling it extreme is put forth at the very
begining, in effect saying "we call this extreme programming, it is
taking practices that have proven their worth and turning the dail to
11" it's fitting and if the biggest roadblock we have is the name
something is odd. People can't even learn to capitalize Scrum properly
and keep refering to it as SCRUM as if it's some sort of acronym, also
the secondary non-rugby meaning of Scrum is:
"2. British. a place or situation of confusion and racket; hubbub."
None of theese issues seems to inhibit Scrum adaption.
I really like this idea. SoftwareCrasftsmenGuild.org People put their resumes out if they are looking for work, and you can follow the chain of trust back to those who vouched for them. The legal pitfalls abound, but I think the idea is a very good one.
On Feb 12, 2009, at 8:30 , Micah Martin wrote:Anyhow, a social networking web site seems like the best medium for
such a community. I have many ideas for how such a site should work.
----Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com