Over-analysing Craftsmanship
Jason Gorman
software craftsmanship thing.
To me it seems very simple and clear-cut:
We care. We learn. We PRACTICE (and there's Waldo!). We share.
* We care about the quality of the work we do. It should be as good as
we're capable of making it.
* We learn from our mistakes, we learn from the examples set by
others. We learn from books and blogs and webinars, from magic beans
and electric parsnips. When we're exposed to good examples, we learn
better. So it's important to have good influences. If your guitar idol
is Al Di Meola, you'll probably turn out to be a more capable player
than if you followed Pete Doherty.
* We share what we've learned. That's the other side of the learning
coin. Who sets the examples? Who writes the blogs, and creates the
screen captures and dos the voodoo on the magic beans? We do, right?
We are all simultaneously masters and apprentices, teachers and
students, mentors and mentored, coaches and coachees.
* Most importantly - and this defines the whole movement as far as I'm
concerned - we learn by doing. We PRACTICE. Continously. Like an
athlete or a pianist or a circus clown or a lion tamer, we now that
what we have to know and apply is far more than can be applied
consciously. We must internalise our knowledge and build our "software
development muscles" and the necessary reflexes and muscle memory
needed to be a productive programmer. This is where I think we have
been going wrong all these years; we've been treating software
development as an entirely intellectual pursuit, one you can master
(there's that word that's going to get us into trouble!) by reading
books or watching other people do it. Which is hogwash. You can no
more master a skill like refactoring by reading a book on it than you
can master riding a bicycle by reading the manual. It takes practice.
lots and lots of practice. Good practice. Focused practice. Measured
practice.
The care, and the learning and the sharing are nothing new. We've been
doing it for decades in the software development community. The focus
on practice, practice, and more practice is a development, I think.
That's our USP, I really believe it:-)
Hi, BTW.
Jason Gorman
http://www.codemanship.com
Dave Rooney
> I can't help feeling we might be thinking too hard about the whole
> software craftsmanship thing.
>
> To me it seems very simple and clear-cut:
>
> We care. We learn. We PRACTICE (and there's Waldo!). We share.
>
I like this.
> * We care about the quality of the work we do. It should be as good as
> we're capable of making it.
>
> * We learn from our mistakes, we learn from the examples set by
> others. We learn from books and blogs and webinars, from magic beans
> and electric parsnips. When we're exposed to good examples, we learn
> better. So it's important to have good influences. If your guitar idol
> is Al Di Meola, you'll probably turn out to be a more capable player
> than if you followed Pete Doherty.
>
Hmmm... mine is Keith Richards. That certainly explains a few things. ;)
> * We share what we've learned. That's the other side of the learning
> coin. Who sets the examples? Who writes the blogs, and creates the
> screen captures and dos the voodoo on the magic beans? We do, right?
> We are all simultaneously masters and apprentices, teachers and
> students, mentors and mentored, coaches and coachees.
>
> * Most importantly - and this defines the whole movement as far as I'm
> concerned - we learn by doing. We PRACTICE. Continously. Like an
> athlete or a pianist or a circus clown or a lion tamer, we now that
> what we have to know and apply is far more than can be applied
> consciously. We must internalise our knowledge and build our "software
> development muscles" and the necessary reflexes and muscle memory
> needed to be a productive programmer. This is where I think we have
> been going wrong all these years; we've been treating software
> development as an entirely intellectual pursuit, one you can master
> (there's that word that's going to get us into trouble!) by reading
> books or watching other people do it. Which is hogwash. You can no
> more master a skill like refactoring by reading a book on it than you
> can master riding a bicycle by reading the manual. It takes practice.
> lots and lots of practice. Good practice. Focused practice. Measured
> practice.
>
Facilitated practice? Mentored practice?
> The care, and the learning and the sharing are nothing new. We've been
> doing it for decades in the software development community. The focus
> on practice, practice, and more practice is a development, I think.
> That's our USP, I really believe it:-)
>
I'm (yet again) reminded of my Father-in-law who held an Aircraft
Maintenance Engineer (AME) licence for over 60 years. To obtain one in
Canada now, a person must have attended 1000 hours of instruction at an
approved institution, complete 48 months of work as an apprentice under
another certified AME, and pass the written exams. There are also
recency requirements.
Now, I fully understand that the breadth of technology in the IT world
is much greater than that of aviation, but I believe there's something
to be learned here. First 1000 hours of instruction is only about 25
weeks in a classroom. Obviously, the regulators see that you require
much more guided or mentored hands-on experience than you do theoretical
training. Is that possibly a model we should consider?
--
Dave Rooney
Mayford Technologies
"Helping you become AGILE... to SURVIVE and THRIVE!"
http://www.mayford.ca
http://practicalagility.blogspot.com
Twitter: daverooneyca
Raoul Duke
> software craftsmanship thing.
> To me it seems very simple and clear-cut:
> We care. We learn. We PRACTICE (and there's Waldo!). We share.
i don't mean to be a jerk, but... :-)
look, anything can be sloganized. but that runs the risk of people
misunderstanding it. i mean, even you didn't just leave the slogan,
you had to explain what it meant. which means you already aren't doing
something "very simple and clear-cut" to other people, you already
have to explain to them what you mean, because humans easily have
different interpretations of words.
my only point being that if you want things to really be communicated,
i do not believe there are any solutions which can remain simple.
sincerely.
Lance Walton
Adewale Oshineye
I have a solution. We say these are our principles:
We care. We learn. We PRACTICE. We share. If you want to know more
then come and talk to us.
If we can stop there then we've got something valuable. I'll stop now.
Torbjörn Gyllebring
What did I learn?
What did I share?
Michael Hunger
Michael
Am 08.04.2009 22:16 Uhr, schrieb Torbjörn Gyllebring:
> Every day ask yourselves:
> What did I learn?
> What did I share?
>
--
Michael Hunger
Independent Consultant
Web: http://www.jexp.de
Email: michael...@jexp.de
Enthusiastic Evangelist for Better Software Development
Don't stop where you are: http://creating.passionate-developers.org
Sign the Software Craftsmanship Manifesto at: http://manifesto.softwarecraftsmanship.org
We support Software Engineering Radio (http://se-radio.net)
Ralf Westphal
Craftsmanship is all about, then pretty much any developer you ask
could claim to be a Software Craftsman:
> We care.
Show me the developer who´d say: "I don´t care about the software I
write."
>We learn.
Show me the developer who´d say: "I don´t learn from my mistakes. And
I also refuse to learn otherwise."
>We PRACTICE (and there's Waldo!).
day. That´s what their job is all about.
Or do you mean practice as in exercise or training? Well, then, how
much time do Software Craftsman invest into such practicing? Because
practicing means you cannot rely on achieving a goal. That´s the very
definition of practice/exercise.
>We share.
Well, this might be true of Software Craftsmen. "Regular" developers
don´t care much about sharing.
So out of 4 attributes of Software Craftsmanship 3 are rightly found
in any ordinary developer, I´d say. What, then, is it really, that
distinguishes Software Craftsmen from the rest?
-Ralf
Jason Gorman
If we go into detail we quickly realise that we all have our own ideas
about what software craftsmanship really is and a genuine, meaningful
consensus on anything beyond a very small scale becomes unachievable.
If we keep things at an abstract-enough level where consensus is
possible we end up making Barnum statements that pretty much everyone
will think applies to them.
We can talk ourselves in circles or all go off and formulate our own
niche definitions of what it means to be a "software craftsman".
Or.... we could acknowledge that any attempt to articulate what we
mean is ultimately doomed, just as it was for Agile, and stop wasting
time trying.
If you want us to know what you mean by caring, or what you mean by
practicing, or what you mean by sharing etc, and how that differs from
what others might mean by it, then _show_ us. Let your code do the
talking.
The first rule of software craftsmanship is that you do not talk about
software craftsmanship ;-)
Jason Gorman
www.codemanship.com
Raoul Duke
> software craftsmanship ;-)
while i very much appreciate that perspective (both seriously and
jokingly), it would be sad to me if discussion around Agile, or
Craftsmanship, or any such thing, suddenly stopped all together.
having said that, yeah, people talk too damned much vs. actually doing
things. that goes in triplicate for myself.
sincerely.
Dotan N.
it should be: tools (mental, and software) and experience, nothing more.
Lance Walton
developers who believe one or more of the following:
* The pressures of software development inevitably means that code
will be crap
* If the architecture is good, it doesn't matter if the code is crap
* All codebases will be crap after a couple of years due to the
unavoidable accretion of ... crap
* It is inevitable that you will need a support team at least the size
of your development team and they will be dealing mostly with data
integrity problems and unavoidable RuntimeExceptions
* Classes are a place into which you shovel your data and functions
* It's best to have your functions outside of your 'domain model'
* Anything above procedural thinking is academic stuff
* etc.
A lot of them thought that they were good developers. Some even
thought that they were engineers. I don't think that they are either
of those things.
I certainly don't think that they are craftsmen.
Now, I know that you are talking about what they think of themselves
and you were also talking about how they would respond to Jason's
points. I kind of agree that those points become non-points if nobody
would contest them. There are a lot of developers out there who would.
Most of them seem to work in investment banks.
Finally, on the issue of 'practice'. Practice is not about doing
either real stuff of exercises. It is about reflecting and adapting in
response to what you find as you do. So many developers are so
concerned with just bashing something until it can be said to be done
until it hits testing or the users, that you can plainly see that
there is no reflection that comes at anywhere near the appropriate
time to allow suitable adaptation (i.e. the feedback loop is far too
long). It is relatively rare to find people who can both 'do' and be
mindful of their doings simultaneously, and then add on top of that
the humility to recognise that something is wrong and the analytical
ability to figure out what it might be, followed by the inventiveness
to come up with a different way and the tenacity required to pursue
it, and you have a very rare individual indeed.
Regards,
Lance
Raoul Duke
> thought that they were engineers. I don't think that they are either
> of those things.
here's something that your post made me think about:
the problem is that anybody can have their own metrics, and say that
things are good by their own metrics. and if they don't / won't
question their own metrics, then we're at an impasse. a problem is
that in software it is hard to explain things concretely to /prove/
that somebody's metrics are sorta crap and self-defeating and just not
up to snuff. i don't see a way one can do that any other way than by
straight-forward concrete implementation.
so i suggest something like a Software Craftsmanship Programming Competition.
sincerely.
Kurt Häusler
"Regular developers may solve the right problem, but craftsmen solve the
problem right."
I think about software development as being carried out at two levels.
The basic level is delivering what the customer wants: Requirements
implemented without any immediately visible defects, all acceptance
tests passing etc. Typically they get a big ball of mud that they are
extremely happy with, at least in the short term. Often the cleanliness
of the code is unimportant as the software might not need to be maintained.
The second level is where craftsmanship comes in. Craftsmen deliver what
the customer should have wanted had the customer more knowledge about
software development: Requirements implemented without any immediately
visible defects, all acceptance tests passing, and a clean code base,
free of technical debt, and free of any violations of good software
design, so that the customer remains satisfied months later, as new
features and bug fixes are made a lot quicker and easier in comparison
with the big ball of mud delivered by the level one developers.
In the first level we find things like:
Acceptance Testing
QC
Satisfaction of maybe 1 or 2 of the ISO 9126 quality model aspects
Management focussed on productivity
Pleasing the customer today.
Quality = Zero (immediately visible) defects (or worse Quality =
delivering value by satisfying requirements)
Short term planning
Programmers
Delivering of value
In level two we find:
Technical debt management
QA
Satisfaction of most of the aspects of the ISO 9126 quality model
Management focussed on quality
Pleasing the customer today, AND in the future, and making life easier
for other developers.
Quality = Zero (or at least fully accounted) technical debt.
Long term planning
Craftsmen
Delivering of value AND quality
Jason Gorman
craftsmanship?
Jason Gorman
www.codemanship.com
Olof Bjarnason
> "Satisfaction of most of the aspects of the ISO 9126 quality model "
>
> Anyone else care to comment on ISO 9xxx and its relevance to
> craftsmanship?
Blogg: http://olofb.wordpress.com [Sv]
Blog: http://olofb.wordpress.com/tag/english [Eng]
Kurt Häusler
certification the firms can get.
I think it is pretty important to have a QA system of some description,
otherwise quality is just a matter of testing and debugging (ie quality
after the fact, rather than quality built right into the process ). ISO
9001 certification means that you have an audited QA system, built right
into the development process, which is also certified and are presumably
enjoying better quality because of that.
However it is just as good to have a well understood process with QA
built in, it doesn't have to be ISO 9001 certified unless some other
factor such as the company size, or the certification can be seen as a
selling point.
Overall I am slightly on the pro side of neutral regarding ISO 9001.
However 9126 is a different kettle of fish, it simply reminds us that
quality is not just a matter of satisfying requirements, or passing
tests with no noticeable defects but a number of other factors are also
relevant, such as maintainability and testability. Which is something
that all craftsmen should be aware of whether it is enshrined in an ISO
standard or not.
Jason Gorman
craftsmanship's about anything it's about people, practices, skills
and discipline. ISO 9xxx coms from an era when we believed that
mediocre teams following good processes could achieve high quality
results. It turned out to be nonsense, of course :-)
>
> - Show quoted text -
Kurt Häusler
out the managers and non-craftsmen team members more than the craftsmen.
It could possibly help the craftsmen get along with the managers and
non-craftsmen too, such as when the managers are actively suspicious of
any activity they don't understand and is not expressly permitted. Using
the continual improvement facility (that ISO 9001 enforces)
craftsmanship type activities could be standardised in the 9001 QMS so
the manager is obliged to support them. (Of course in this case it is
being used as a workaround for a deeper problem)
So assuming a world where craftsmen have to work with other people in
the organisation such as managers and non-craftsmen developers, I am
still on the slightly pro side of neutral.
No scratch that, I forgot how much processes suck, I am switching to
neutral on the 9001 issue.
However 9126 should be on every craftsman's wall.
Antony Marcano
> The first rule of software craftsmanship is that you do not talk about
> software craftsmanship ;-)
We care, we learn, we practice, we share...
All rolled up into one neat package http://pairwith.us/trailer
And by practice, I mean practice away from the usual commercial
pressures so I have plenty of scope to experiment and try different
things so I can be faster and better when it's the 'real'
performance... when we're working on something where commercial
pressures prevail.