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
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
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?
"Helping you become AGILE... to SURVIVE and THRIVE!"
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.
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.
Am 08.04.2009 22:16 Uhr, schrieb Torbjörn Gyllebring:
> Every day ask yourselves:
> What did I learn?
> What did I share?
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)
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.
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.
"Regular developers may solve the right problem, but craftsmen solve the
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:
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
Delivering of value
In level two we find:
Technical debt management
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
Delivering of value AND quality
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
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.
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.