Well, I'd like to tell you why I am involved in this group.

I got involved because, obviously, I care about code. I'm sick of bad code.

Bad code isn't just ugly, it obscures the meaning of the functionality.  If
the developer didn't care enough (or lacked the skills to) write the code
well, he probably introduced errors into the algorithms.  But, because the
code is so ugly (and it probably lacks automated tests), we can't see them.

That means that over time, the code becomes more expensive to maintain and
your work like becomes no fun.

Now, the odd thing is that most corporate american roles tend to subtly
encourage this behavior. After all, a quick hack now will guarentee me the
boss's approval.  And, why, we might never have to touch the code again.
And if we do have to touch it, I might not be on this team.  And if I am on
the team, we can probably give it to the new guy.

I'm interested in ways to change the system.  Last summer, I organized the
tech debt workshop (sponsored by the Agile Alliance), we made less headway
that I would have hoped.  One of the main conclusions that several people
came to was that the "problem" with tech debt could be solved by better
management.

While that is appealing, on some level I diagree:  Management doesn't
actually write the code, test it, or change it.  When we lay the blame at
the feet of management, we are missing the fact that it is the technical
people who actually make the shortcuts.

I see a craft model doing two things: It provides training (to avoid the
ignorance problem) through real tangible example, and it gives some sort of
professional code of ethics ("I will not do crap work") which may, perhaps,
maybe, over-ride the desire of some to pass responsibility off to the boss.
("The boss put me under incredible time pressure to take short-term
optimizations!  It is his fault!")

So, in that way, I would like to extend the model to beyond the borders of
my shop.  That is, I believe, a good part of the idealistic reason people
give speeches and write books and such - to impact the industry.

That is why I would support a /good/, /optional/ program involving
commitment to ethical behavior and formal training.

But I'm open to discussion either way.

regards,

--
Matthew Heusser,
Blog: http://xndev.blogspot.com
Twitter: http://www.twitter.com/mheusser
Skype: mattheusser

The same goes for at least one german company. Three years ago I started fresh
from university as a tester and dived into the topic. There are two re-occuring
patterns:
- the code gets tested afterwards, I don't need to bother (my favourite one - a
similar view is the confusion of try-out and testing, which I sense sometimes
during conversations)
- ugly code

While the first one is quite self-explanatory and almost every tester has had
an experience like this, the second one is harder to describe.

One or two weeks ago I was made aware of SqueakyCleanCode and
ScreechinglyObviousCode (http://c2.com/cgi/wiki?ScreechinglyObviousCode). When
I take a look into the source code branches, I rarely see
ScreechinglyObviousCode, I'm maybe able to see SqueakyCleanCode, but most of
the time I just see ugly code.

If I understood you right, I wouldn't dare to say that it's not just an
American problem you described.

Kind regards
Markus Gärtner

I would also want to add that it is very frustrating at times to work with
some APIs.

Even when you care about your craft, it gets difficult to produce something
you are really proud of because you have to use some broken 3rd party
framework or component. Some of them make your code impossible to test.

It might be a good aim to leave the code better than it was when you found
it but sometimes that is not enough.

Nuno

2008/12/16 Markus Gaertner <mgaer...@googlemail.com>

I think this sort of "why I am here" declaration is a good idea.  And
Matt's email made me ask myself why I am involved in this group and
how I ended up here.

First, I would like to start out by recommending that anyone who is
serious about software craftsmanship go out and read Pete McBreen's
book "Software Craftsmanship".  I think it's a critical starting place
for these discussions, and on a more personal note, the book had a
huge impact on me.  Probably the biggest reason I am a part of this
group is that I have no where else to go.  :)  I was a later-in-life
self-taught programmer who had a wife and child(ren) to support from
the day I wrote my first for loop, so I have no formal scientific or
engineering education, and I don't have the option of taking time off
to obtain one.  And yet I want to become great at what I do.  In my
first two years as a programmer I started to despair about my lack of
relevant education.  It seemed that without computer science or
software engineering credentials, I was going to have a hard time
making progress.  But then I read "Software Craftsmanship" and I felt
like I could fit into the world that Pete was describing.  I could see
myself in the story, and I recognized that I was an "apprentice".
This gave me the "career map" I needed which allowed me to take the
steps I needed to make progress.  Neither computer science nor
software engineering provided this map for someone like me.  So,
unlike some people (like Pete) who argue strongly against software
engineering, I am mostly ignorant of it and choose software
craftsmanship because I didn't have any other options.

The steps I took after reading Pete's book obviously shaped the way I
look at software development.  And because these 6 years since I read
Pete's book have been largely positive for me, I would like to
encourage other people to walk a similar path, to help them make
similar progress.  That is one of the reasons I wrote "Apprenticeship
Patterns".  I would also like to improve the apprenticeship experience
and raise the bar for what we expect from someone with 4, 5, or 6
years of experience in our industry.  That is one of the reasons I
started Obtiva's apprenticeship program.  I want to instill a desire
in people to become master craftsmen, which is a very
counter-cultural, yet increasingly important role to play (see
http://search.safaribooksonline.com/0201733862/ch11lev1sec1).

So, I wonder what we as a community can do to improve these things
even more.  I wonder how we can make it easier for companies and
individuals to take on apprentices.  I wonder how we can make it
easier for companies and individuals to host and send journeymen to
spread great ideas between development shops.  And most critically, I
wonder how we can ensure that our master craftsmen stick with the
fundamental activity of actively developing software for long-term
customers (see http://search.safaribooksonline.com/0201733862/ch08lev1sec7).

I'm honestly not interested in any criteria that would allow us to
distinguish an apprentice from a journeyman or a craftsman from a
non-craftsman.  When it comes to a set of principles that a software
craftsman should adhere to, I think Pete's book serves as a good
enough starting point.  I realize now that I'm here because I hope
that we can organize a network of people to encourage the 3 activities
that I've seen make the biggest impact on people becoming software
craftsmen.  I'm here because I'd like to see us:

1) Facilitate the introduction of apprenticeships, similar to 8th
Light's and Obtiva's
2) Create a structure that encourages journeymen to journey between
development shops, similar to Corey Haines' tour
3) Seek out master craftsmen and identify their masterpieces and
contributions to the craft, to provide the rest of us with something
to aspire to

Best,

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

Thank you Dave, I appreciate your pragmatism. I think that searching  
for software craftsmanship values and meaning and hopefully create  
some sort of manifesto is important. But I think the time we dedicated  
at the summit for this was enough. I was hoping to converge at the end  
of the day on a definition of craftsmanship. But we started to  
converge around 4pm and hence the discussion that is going on here.

I have the impression that trying to find those values in their best  
possible form now is like a big design upfront. Let's publish what we  
found until now as "manifesto beta" and refine the rest over time.

The reason why I'm replying to Dave is because I see at the end of his  
reply a list of practical steps. I'm the guy that at the end of the  
summit wrote on the board a small box with some practical steps for  
aspiring craftsmen. Those are just ideas, but the principle is how an  
aspiring craftsman can improve their skills, identify a master  
craftsman and when to set the transition from apprentice to craftsman.

I'm thinking about a [cross-company] network and a way to identify our  
master craftsman. Here's some other interesting ideas:

- Coding dojos: monthly coding dojo and some way to track who is  
attending. Maybe we should consider a minimum of 10 dojos to attend  
for an apprentice to become a craftsman. The dojo can be pairing with  
a master craftsman. Or what we did with Uncle Bob recently at 8thlight.
- Masterpieces: as Dave said we should know masterpieces. Both books  
and software I think. Reading groups? Source code retrospective groups?
- Exams? How to set the transition to a next level? I should be able  
to demonstrate my skills executing katas or maybe solving a small  
algorithm in front of a master craftsman jury.
- Portfolio. Bring together the relevant part of your work to  
demonstrate what you are capable of. The apprentice should be helped  
out identifying and collect those pieces maybe in a common place for  
everyone to see.

Well, hope I gave you the idea of the direction I'd like to give to  
the discussion.

Renzo

On Dec 17, 2008, at 5:04 AM, Dave Hoover wrote:

On Dec 17, 2:50 pm, Renzo Borgatti <renzo.borga...@gmail.com> wrote:

That sounds like an encouragingly Agile approach!

I don't know about you, but restrictive NDAs and company IT security
policies effectively prevent me from talking about, let alone showing
people my work :(

I have that too, but I also have projects that I contribute to on my own
time. In many cases, this is a better demonstration of my abilities because
it's completely under my control.

Ben