To Test or Not to Test? That’s a Good Question.

[Dave Hoover]

An interesting experience report from a master
http://www.threeriversinstitute.org/blog/?p=187

Best,

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

[Curtis Cooley]

On Fri, May 15, 2009 at 9:40 AM, Dave Hoover <dave....@gmail.com> wrote:
>
> An interesting experience report from a master
> http://www.threeriversinstitute.org/blog/?p=187
>

That post scares the hell out of me. Well, not that bad, but boy does
it open up a can of worms.

"I mean, after all, Kent Beck himself said I don't have to test this."

--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.

[Anthony Broad-Crawford]

On May 15, 2009, at 12:59 PM, Curtis Cooley wrote:

On Fri, May 15, 2009 at 9:40 AM, Dave Hoover <dave....@gmail.com> wrote:

An interesting experience report from a master

http://www.threeriversinstitute.org/blog/?p=187

That post scares the hell out of me. Well, not that bad, but boy does
it open up a can of worms.

"I mean, after all, Kent Beck himself said I don't have to test this."

I can't speak for all situations, companies or projects, simply my own.  I come from a start-up, and typically in a start-up "time" is the one thing you don't have.  You usually handle  four weeks worth of work crammed down into two.  Then rinse, wash, and repeat.  So to us, the question "is" whether to test or not.  We constantly ask if we should  writes tests first, later, none at all, acceptance, and or unit.  Sometimes, it is better to have two additional product enhancements added this iteration then one product enhancement with tests.  We continue to make these decisions everyday and review frequently as a team.  To me, the muscle that is driving our ability to make the correct decision in those situations is  the one we are trying to strengthen.  A simple "always write tests no matter what  and don't ever even stop to think is this appropriate for this specific situation" really isn't what we should be practicing in my opinion.  

--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.

Anthony Broad-Crawford

www.anthonybroadcrawford.com

www.twitter.com/broadcrawford

This email is:   [ ] bloggable    [X] ask first   [ ] private

[Kevlin Henney]

2009/5/15 Dave Hoover <dave....@gmail.com>:

>
> An interesting experience report from a master
> http://www.threeriversinstitute.org/blog/?p=187

Interesting indeed. However, the title is not strictly correct. It is
important to keep in mind that the word "test" is heavily overloaded
and its interpretation is very context dependent. What Kent is
actually talking about is not whether to test or not, but whether to
test automatically or manually first. This is a subtle but important
distinction, but it turns it largely into a question of timing.

Regardless of whether I agree with Kent or not, I think there are some
key points not mentioned in the article and a couple of false
assumptions.

Kevlin

[Robert Hanson]

This is a great post, and will have strict TDD'ers questioning "the
faith", and have "0-known-bugs-maxim" (and other 0-tolerance idioms)
followers wondering if it ok to let a bug or two slide if it makes
sense.

I do think that for some developers it makes sense to follow the
rules, but experts need to have free will (see:
http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition). I
put myself in the expert category, sometimes, depending on the subject
matter, which is why I am often against the black-and-white arguments
I see on this list. I see things in more shades of gray.

So I agree with Kent, but maybe for the sake of others, he should have
kept his thoughts to himself ;)

Rob
http://www.google.com/profiles/IamRobertHanson

[Anthony Broad-Crawford]

On May 16, 2009, at 8:57 AM, Robert Hanson wrote:

This is a great post, and will have strict TDD'ers questioning "the
faith", and have "0-known-bugs-maxim" (and other 0-tolerance idioms)
followers wondering if it ok to let a bug or two slide if it makes
sense.

I do think that for some developers it makes sense to follow the
rules, but experts need to have free will (see:
http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition).  I
put myself in the expert category, sometimes, depending on the subject
matter, which is why I am often against the black-and-white arguments
I see on this list.  I see things in more shades of gray.

It's always a shade of gray!  +1 +1 +1 +1 +1 

So I agree with Kent, but maybe for the sake of others, he should have
kept his thoughts to himself ;)

I don't think there is anything wrong with teaching or promoting the fact that it isn't always a cut and dry, black and white, situation and that we should be critically thinking about the actions we are taken in any given situation.

Rob
http://www.google.com/profiles/IamRobertHanson



On Fri, May 15, 2009 at 12:40 PM, Dave Hoover <dave....@gmail.com> wrote:

An interesting experience report from a master

http://www.threeriversinstitute.org/blog/?p=187

Best,

Dave Hoover

//obtiva:  Agility applied. Software delivered.

Anthony Broad-Crawford

Vice President and Chief Technology Officer @ Within3

Dataportability Project Steering Committee and Healthcare Taskforce Chair

[Olof Bjarnason]

I think one relevant idea Kent brings up is feedback flow. If we focus
on getting that flow-per-unit-time high, we are heading in the right
direction.

For example, he mentions short-term untested-features-adding being a
maximizer of feedback-flow in the beginning of the JUnitMax project,
since writing the first test was so darn hard to write (took him over
a week). He got a higher feedback-flow by just hacking it together and
releasing; his “red tests” were the first few users and their
feedback.

I’d like to examine that idea more, for example, it does not mention
the feedback delay; only the feedback volume/flow. To me, delay is at
least as important as feedback volume.

2009/5/16 Anthony Broad-Crawford <ant...@anthonybroadcrawford.com>:

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

[Curtis Cooley]

On Sat, May 16, 2009 at 8:18 AM, Olof Bjarnason
<olof.bj...@gmail.com> wrote:
>
> I think one relevant idea Kent brings up is feedback flow. If we focus
> on getting that flow-per-unit-time high, we are heading in the right
> direction.
>
> For example, he mentions short-term untested-features-adding being a
> maximizer of feedback-flow in the beginning of the JUnitMax project,
> since writing the first test was so darn hard to write (took him over
> a week). He got a higher feedback-flow by just hacking it together and
> releasing; his “red tests” were the first few users and their
> feedback.
>
> I’d like to examine that idea more, for example, it does not mention
> the feedback delay; only the feedback volume/flow. To me, delay is at
> least as important as feedback volume.
>

There is a subtlety to the post that I have not seen anyone mention.
Kent tested everything, although he did it in an "outside the box"
way. Actually, he didn't perform the tests, his early adopters did.
And they didn't even know it. Kent provided a way for errors in the
applications to be reported behind the scenes. Then, he could fix the
bugs his testers found.

The other subtlety was his mention of acceptance tests. I got the
impression he did not acceptance test drive the development of Max. He
did not mention whether or not he unit tested, or TDDed.

And for those in startups that think they need to go fast:
http://butunclebob.com/ArticleS.UncleBob.SpeedKills
http://www.artima.com/weblogs/viewpost.jsp?thread=51769

[Curtis Cooley]

On Sat, May 16, 2009 at 5:57 AM, Robert Hanson
<iamrobe...@gmail.com> wrote:
>
> This is a great post, and will have strict TDD'ers questioning "the
> faith", and have "0-known-bugs-maxim" (and other 0-tolerance idioms)
> followers wondering if it ok to let a bug or two slide if it makes
> sense.
>

Pragmatism beats dogmatism every time, but us "black and white 0-bug
tolerance" folks still think that it's important to strive for 0-bugs,
or perfection, or whatever seems too hard for the "shades of gray my
project is special folk", and continually improve our process instead
of accepting mediocrity because somehow our special circumstances do
not apply. I do not expect to ship with 0-bugs, but that does not stop
me from striving for 0-bugs.

[Corey Haines]

Anthony's point is a reality for a lot of people. Unfortunately, it is a prime example of the current state of our industry as it relates to Ron Jeffries' first comment (and Dave's) on Kent's post: the danger of people who don't have the necessary experience with TDD or automated testing misusing the intent/usage of the post.

The reality of the startup, as I've spoken to and heard from people, is not that testing/TDD is inappropriate due to speed; it is that a startup environment is not conducive to on the job learning. If you do not have the necessary skills with a technique to be rapid with it, then trying to use it will slow you down. When you put yourself in the situation to  be under constant and extreme deadline pressures, you are accepting the reality of not allowing effective improvement in skills. Rather than saying that 'xxx technique is not appropriate,' it is more honest to say that 'learning xxx technique is not appropriate.' The 'XXX or not XXX' argument is a question of skill and experience. Doing things you are not comfortable with/experienced in, regardless of whether you believe they are good, is going to sleep you down. In this discussion, replace 'test' with 'object-oriented design guidelines' and think about 15-20 years ago.

-Corey

--
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines

[Anthony Broad-Crawford]

Speed "can" kill you.  It isn't guaranteed.  The art, the skill, is to know when it is killing you and what the next steps to solving the problem are.

--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.

[Anthony Broad-Crawford]

On May 16, 2009, at 1:07 PM, Corey Haines wrote:

Anthony's point is a reality for a lot of people. Unfortunately, it is a prime example of the current state of our industry as it relates to Ron Jeffries' first comment (and Dave's) on Kent's post: the danger of people who don't have the necessary experience with TDD or automated testing misusing the intent/usage of the post.

Then we should be educating on why in that scenario that was a correct decision (if in fact it was).

The reality of the startup, as I've spoken to and heard from people, is not that testing/TDD is inappropriate due to speed; it is that a startup environment is not conducive to on the job learning. If you do not have the necessary skills with a technique to be rapid with it, then trying to use it will slow you down. When you put yourself in the situation to  be under constant and extreme deadline pressures, you are accepting the reality of not allowing effective improvement in skills. Rather than saying that 'xxx technique is not appropriate,' it is more honest to say that 'learning xxx technique is not appropriate.'

'learning xxx technique is not appropriate.' That is probably the best way I have heard it articulated.  However, I would add at the end "at this time" so the full statement is 

"Learning xxx technique is not appropriate at this time"

with an immediate follow up of "when is the correct time?" because you should always be evaluating when "is" the correct time.  However, isn't this where practice comes into play?  If I am lacking in a particular skill, and it isn't appropriate to do it "on the fly with the current project" I should be practicing at home so I can employ the xxx technique next time.  Thoughts?

[Anthony Broad-Crawford]

On May 16, 2009, at 12:01 PM, Curtis Cooley wrote:

On Sat, May 16, 2009 at 5:57 AM, Robert Hanson
<iamrobe...@gmail.com> wrote:

This is a great post, and will have strict TDD'ers questioning "the

faith", and have "0-known-bugs-maxim" (and other 0-tolerance idioms)

followers wondering if it ok to let a bug or two slide if it makes

sense.

Pragmatism beats dogmatism every time, but us "black and white 0-bug
tolerance" folks still think that it's important to strive for 0-bugs,
or perfection, or whatever seems too hard for the "shades of gray my
project is special folk", and continually improve our process instead
of accepting mediocrity because somehow our special circumstances do
not apply. I do not expect to ship with 0-bugs, but that does not stop
me from striving for 0-bugs.

We should always be striving for the best.  When we fall short of it, we should be taking a step back and evaluating why we failed.  Then, begin to make changes to improve ourselves (and our teams) to do better next time.  I thought that is what the agile retrospective process (or any professionals internal retrospective process) is for.  No one should ever settle for mediocrity.  

--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.

[Corey Haines]

On Sat, May 16, 2009 at 1:20 PM, Anthony Broad-Crawford <ant...@anthonybroadcrawford.com> wrote:

On May 16, 2009, at 1:07 PM, Corey Haines wrote:

The reality of the startup, as I've spoken to and heard from people, is not that testing/TDD is inappropriate due to speed; it is that a startup environment is not conducive to on the job learning. If you do not have the necessary skills with a technique to be rapid with it, then trying to use it will slow you down. When you put yourself in the situation to  be under constant and extreme deadline pressures, you are accepting the reality of not allowing effective improvement in skills. Rather than saying that 'xxx technique is not appropriate,' it is more honest to say that 'learning xxx technique is not appropriate.'

'learning xxx technique is not appropriate.' That is probably the best way I have heard it articulated.  However, I would add at the end "at this time" so the full statement is 

"Learning xxx technique is not appropriate at this time"

with an immediate follow up of "when is the correct time?" because you should always be evaluating when "is" the correct time.  However, isn't this where practice comes into play?  If I am lacking in a particular skill, and it isn't appropriate to do it "on the fly with the current project" I should be practicing at home so I can employ the xxx technique next time.  Thoughts?

If you feel that there is a better, more effective way to develop software, but you are unskilled in it, it is a personal decision whether you should take the time to practice and internalize it. As an analogy, think about wood-working. There are tools that, once learned, can make a world of difference in the effectiveness of your building techniques. Until you learn them, though, they slow you down and perhaps even work against you. Trying to learn to use the tool while actually building things is not the most effective to learn the tool. Instead, you would go about using the tool to build very small projects, learning to handle it appropriately and efficiently for specific tasks.

On-the-job training on production systems is inefficient at best, counter-productive to the business at worst. In the situation you describe, when you are at the type of startup where the emphasis is on the continual, rapid-as-possible development/deployment of new features, then it is a decision that has to be made as a team whether you begin to try 'new things' which can slow you down. Whether practice is done is a combination of the values of the person (whether they do it at home) and the values of the company (whether time is allotted for focused practice outside of feature development). In our situation, it sounds like the long-term maintainability/flexibility of the situation is not the goal, as in Kent's explanation of the short-game. In this case, hacking out a system as quickly as possible trumps spending the time to learn techniques for effectively building truly long-lived systems.

The important thing is to differentiate between 'XXX technique is not appropriate' and 'learning XXX technique is not appropriate.' Without the necessary experience and skills, it is impossible to answer the former. The dangerous part of Kent's post is when people who do not have the necessary skills think they have the background to make that decision. Here is a quote from Kent's post:
<quote>The second defect posed a dilemma. I could see how to fix the problem, but I estimated it would take me several hours to learn what was necessary to write an automated test. My solution: fix it and ship it. No test.</quote>
Notice that he is not saying the testing wasn't needed, he said that he chose not to take the time to 'learn what was necessary' to do the automated test. Unfortunately, too often what happens is that people look at Kent's statements, then exhibit the hubris that they have even remotely the same amount of experience/skills as he does in developing long-lived systems and can make the decision that he does.

-Corey

 

[LudovicoVan]

On 15 May, 17:40, Dave Hoover <dave.hoo...@gmail.com> wrote:
> An interesting experience report from a masterhttp://www.threeriversinstitute.org/blog/?p=187

Most of the projects I have worked on for the last 15 years or so,
i.e. business systems (never mission critical, sometimes business
critical), belong to a third category: in Beck's terminology, I'd call
it "short-long term projects".

I mean those projects characterised by the fact that the system or
application is expected to be operational for an indefinite amount of
time: all maintenance that is conceived is some eventual bug fixing,
and some very rare and minor extensions. Should the business go
through an internal restructuring, so that the process changes, they
would just commission an "new system", in practice a brand new
development project.

That premise to get to this practical point: as far as I have seen, in
the domain of these "short-long term projects", which I would think
covers most of the actual business development, so a good share of the
software market, regression testing on a side, and acceptance testing
on the other, are quite enough as far as testing goes, even in an
agile setting (I mean, low formality), provided that there is on top a
discipline to (at least) proper analysis on a side, and a clean code-
base on the other.

-LV

[Corey Haines]

I posted a video with some of my thoughts on this, nothing too much more than our discussion: http://vurl.me/UH

-Corey

[LudovicoVan]

On 16 May, 19:35, Corey Haines <coreyhai...@gmail.com> wrote:

> If you feel that there is a better, more effective way to develop software,
> but you are unskilled in it, it is a personal decision whether you should
> take the time to practice and internalize it. As an analogy, think about
> wood-working. There are tools that, once learned, can make a world of
> difference in the effectiveness of your building techniques. Until you learn
> them, though, they slow you down and perhaps even work against you. Trying
> to learn to use the tool while actually building things is not the most
> effective to learn the tool. Instead, you would go about using the tool to
> build very small projects, learning to handle it appropriately and
> efficiently for specific tasks.

I quite suppose this is not what you meant, but here you seem to be
suggesting tool-based development. The key skills, those that really
make a difference, have nothing to do with learning to use tools. This
is more or less trivial, but maybe a couple of examples might help the
newbies: you won't become a designer by learning how to apply some
filters in Photoshop; you won't become a musician by learning how to
hack a way through Cubase; you won't become a proficient software
professional by learning VS, or SVN, or ScrumDesk, or anything like
that.

> On-the-job training on production systems is inefficient at best,
> counter-productive to the business at worst.

This might be true only in theory: as a matter of fact, in most
software factories, people already work over-time, all the time!
(Thanks to incompetent software managers: "permanent emergency" I call
it.) Then, training on-the-job, meant as learning new skills while
going, is in most cases the only option.

Moreover, and FWIW, I completely disagree with this approach to
"practice": IMO, if something distinguishes a mature software
developer from a non-mature one, that is indeed that there is not,
there cannot be, and there should not be, any distinction between
working and practicing.(This might be elaborated furtherly, if
needed.)

-LV

[James Martin]

On Wed, May 20, 2009 at 12:16 PM, LudovicoVan <ju...@diegidio.name> wrote:

On 16 May, 19:35, Corey Haines <coreyhai...@gmail.com> wrote:

> If you feel that there is a better, more effective way to develop software,
> but you are unskilled in it, it is a personal decision whether you should
> take the time to practice and internalize it. As an analogy, think about
> wood-working. There are tools that, once learned, can make a world of
> difference in the effectiveness of your building techniques. Until you learn
> them, though, they slow you down and perhaps even work against you. Trying
> to learn to use the tool while actually building things is not the most
> effective to learn the tool. Instead, you would go about using the tool to
> build very small projects, learning to handle it appropriately and
> efficiently for specific tasks.

I quite suppose this is not what you meant, but here you seem to be
suggesting tool-based development. The key skills, those that really
make a difference, have nothing to do with learning to use tools. This
is more or less trivial, but maybe a couple of examples might help the
newbies: you won't become a designer by learning how to apply some
filters in Photoshop; you won't become a musician by learning how to
hack a way through Cubase; you won't become a proficient software
professional by learning VS, or SVN, or ScrumDesk, or anything like
that.

Maybe if you substitute "tool" for  "application of a technique, using a tool" then Corey's video and message will make more sense. At least, that's the mental leap I made.

Writing a useful test is actually more of a skill or technique, but I also need to know how to apply that technique effectively to my materials (code) and that requires that I learn how to use a tool.

So, I agree with you: learning how to use the functionality of my test framework (tool) without ever actually learning how to write a useful test is not really going to make me a well-rounded developer.

> On-the-job training on production systems is inefficient at best,
> counter-productive to the business at worst.

This might be true only in theory: as a matter of fact, in most
software factories, people already work over-time, all the time!
(Thanks to incompetent software managers: "permanent emergency" I call
it.) Then, training on-the-job, meant as learning new skills while
going, is in most cases the only option.

Taking the time to learn a technique, skill or tool outside of your work in controlled practice sessions is always an option. If you can't make time for practice or move to a working environment that encourages it, then you're probably not dedicated to the craft.

And that's OK. No one is forcing anyone else to be a craftsman.
 

Moreover, and FWIW, I completely disagree with this approach to
"practice": IMO, if something distinguishes a mature software
developer from a non-mature one, that is indeed that there is not,
there cannot be, and there should not be, any distinction between
working and practicing.(This might be elaborated furtherly, if
needed.)

I think further elaboration is needed. I'm not clear what you're saying here. You seem to be intimating that just by working in a profession, without any clear plan, one can somehow become skilled in a craft. Maybe I'm just having a dumb moment, but I don't see how that logically follows. 


Thanks,
James.

[LudovicoVan]

On 20 May, 03:41, James Martin <jimmymar...@gmail.com> wrote:

> So, I agree with you: learning how to use the functionality of my test
> framework (tool) without ever actually learning how to write a useful
> test is not really going to make me a well-rounded developer.

My point is: it's not gonna make you a developer *at all*. A carpenter
surely needs to know how to properly use a hammer, but learning to use
a hammer won't make you a carpenter. (BTW, we could also remember that
know-how is not know-what.)

> If you can't make time for practice or move to a working environment
> that encourages it, then you're probably not dedicated to the craft.
> And that's OK. No one is forcing anyone else to be a craftsman.

I'd just strongly disagree: on this idea of the preminence of
"practice", which is anyway strictly related to the overall idea of
what craftsmanship may mean. Of course, I have noted the widespread
emphasis on practice, so I understand my position needs to be better
qualified.

> I think further elaboration is needed.

I'll certainly try. Unfortunately, not until tomorrow; today is going
to be a long day...

-LV

[James Martin]

On Wed, May 20, 2009 at 3:04 PM, LudovicoVan <ju...@diegidio.name> wrote:

On 20 May, 03:41, James Martin <jimmymar...@gmail.com> wrote:

> So, I agree with you: learning how to use the functionality of my test
> framework (tool) without ever actually learning how to write a useful
> test is not really going to make me a well-rounded developer.

My point is: it's not gonna make you a developer *at all*. A carpenter
surely needs to know how to properly use a hammer, but learning to use
a hammer won't make you a carpenter. (BTW, we could also remember that
know-how is not know-what.)

OK. I think we're violently agreeing on this. :)

> If you can't make time for practice or move to a working environment
> that encourages it, then you're probably not dedicated to the craft.
> And that's OK. No one is forcing anyone else to be a craftsman.

I'd just strongly disagree: on this idea of the preminence of
"practice", which is anyway strictly related to the overall idea of
what craftsmanship may mean. Of course, I have noted the widespread
emphasis on practice, so I understand my position needs to be better
qualified.

In that case, I feel like I've missed a post you've made in the past explaining your position on that.

> I think further elaboration is needed.

I'll certainly try. Unfortunately, not until tomorrow; today is going
to be a long day...

I know the feeling. Good luck with it!


James.

[Steven Smith]

I agree with Corey on this 100%. We've done the pragmatism vs
dogmatism debate before and it really comes down to whether or not the
team already has the requisite skill to perform at XXX level of
(desired attribute), and if they do not, whether there is enough slack
in the organization to allow for the necessary learning to bring them
up to that level. If there
is not, it's often an organizational decision to ship what you can as
fast as you can rather than investing the time to train up resources
so they can reach a certain bar.

Steve

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

[Corey Haines]

The main thing that I want to stress is that, as aspiring craftsman, we need to stop making excuses, hiding things with fancy words (pragmatism, dogmatic, technical debt (I much prefer technical bankruptcy for that)) for the severe lack of skill prevalent in our chosen field (ourselves included). We have a tendency to drop these words as ways to make ourselves and others feel better, more comfortable, with the fact that we, or others, are not willing to take the time to learn to do their best. Honesty, as I mentioned in a previous video, is essential: honesty in our experience, honesty in our skills, honesty in the skills of others, honesty in the end-result of our decisions.

It is always an organizational decision as to whether to ship shit, or not. If you work for someone else, it is always their decision. After all, they are paying you. However, as aspiring craftsman, it is essential that, in the case of clients, we are brutally honest in explaining what they are asking for. If they insist, then our choice is to either do it or drop the client. Both are options, the choice of which option is up to each individual. What shouldn't be an option is covering up with pretty words. That happens all too often, and it is detrimental to everyone, most of all the client who may, or may not, understand what they are asking. And, in my opinion, goes against what I consider to be two foundational principles of both agile and software craftsmanship: honesty and courage.

Sadly, our industry it too full of teams that don't have 'the requisite skill to perform at XXX level,' and yet, rather than do what is necessary, we make excuses and cover up the fact that this team, for various reasons, is inadequately skilled. It is a sad testament to our industry that we still ask these teams to perform what is basically an impossible feat. This is setting up for long-term (and often short-term) failure at many levels. If these teams were hired, then they are dishonest, if they are transitioned from other technologies, then the organization is to blame for severe negligence, especially if it is not willing to do what is necessary to increase the chances of success: one, and perhaps the best, option is to hire or temporarily contract a skilled craftsman(s) to work day-to-day with the team, working hard to make sure that the unskilled team is not walking into a trap.

-Corey

[Raoul Duke]

> Sadly, our industry it too full of teams that don't have 'the requisite
> skill to perform at XXX level,' and yet, rather than do what is necessary,
> we make excuses and cover up the fact that this team, for various reasons,
> is inadequately skilled. It is a sad testament to our industry that we still
> ask these teams to perform what is basically an impossible feat. This is
> setting up for long-term (and often short-term) failure at many levels. If
> these teams were hired, then they are dishonest, if they are transitioned
> from other technologies, then the organization is to blame for severe
> negligence, especially if it is not willing to do what is necessary to
> increase the chances of success: one, and perhaps the best, option is to
> hire or temporarily contract a skilled craftsman(s) to work day-to-day with
> the team, working hard to make sure that the unskilled team is not walking
> into a trap.

there are so many things in there which make me say "+1", and then
there's all the related thoughts and feelings i have about the whole
issue which also all make me say, "+1".

sincerely.

[Corey Haines]

On Wed, May 20, 2009 at 5:16 AM, LudovicoVan <ju...@diegidio.name> wrote:

I quite suppose this is not what you meant, but here you seem to be
suggesting tool-based development. The key skills, those that really
make a difference, have nothing to do with learning to use tools. This
is more or less trivial, but maybe a couple of examples might help the
newbies: you won't become a designer by learning how to apply some
filters in Photoshop; you won't become a musician by learning how to
hack a way through Cubase; you won't become a proficient software
professional by learning VS, or SVN, or ScrumDesk, or anything like
that.

You are right, that isn't what I meant. At least, not literally. To me, TDD is a tool in my craftsman chest. I should have been more explicit when I made the analogy. Sorry.


 

> On-the-job training on production systems is inefficient at best,
> counter-productive to the business at worst.

This might be true only in theory: as a matter of fact, in most
software factories, people already work over-time, all the time!
(Thanks to incompetent software managers: "permanent emergency" I call
it.) Then, training on-the-job, meant as learning new skills while
going, is in most cases the only option.

The fact that people already work a lot of over-time is a problem. It isn't just because of 'incompetent managers;' that is an excuse we make. We choose to do it. We choose to allow it to happen.

 

Moreover, and FWIW, I completely disagree with this approach to
"practice": IMO, if something distinguishes a mature software
developer from a non-mature one, that is indeed that there is not,
there cannot be, and there should not be, any distinction between
working and practicing.(This might be elaborated furtherly, if
needed.)

Please do elaborate. I think there is a huge difference between practice and what we do at work. I'm very interested to hear your thoughts.

-Corey
 

[LudovicoVan]

On 21 May, 22:04, Corey Haines <coreyhai...@gmail.com> wrote:
> On Wed, May 20, 2009 at 5:16 AM, LudovicoVan <ju...@diegidio.name> wrote:
>
> > I quite suppose this is not what you meant, but here you seem to be
> > suggesting tool-based development. The key skills, those that really
> > make a difference, have nothing to do with learning to use tools. This
> > is more or less trivial, but maybe a couple of examples might help the
> > newbies: you won't become a designer by learning how to apply some
> > filters in Photoshop; you won't become a musician by learning how to
> > hack a way through Cubase; you won't become a proficient software
> > professional by learning VS, or SVN, or ScrumDesk, or anything like
> > that.
>
> You are right, that isn't what I meant. At least, not literally. To me, TDD
> is a tool in my craftsman chest. I should have been more explicit when I
> made the analogy. Sorry.

Absolutely no problem, and I was sure that was not what you were
suggesting. Rather great that this issue is coming out explicitly.

> > > On-the-job training on production systems is inefficient at best,
> > > counter-productive to the business at worst.
>
> > This might be true only in theory: as a matter of fact, in most
> > software factories, people already work over-time, all the time!
> > (Thanks to incompetent software managers: "permanent emergency" I call
> > it.) Then, training on-the-job, meant as learning new skills while
> > going, is in most cases the only option.
>
> The fact that people already work a lot of over-time is a problem. It isn't
> just because of 'incompetent managers;' that is an excuse we make. We choose
> to do it. We choose to allow it to happen.

I cannot agree on that: it's not the developer's choice, it's rather
their permanent hell. Not only, as a developer, you have no authority
to really question decisions taken without even consulting you,
moreover, and not to forget: even developers have a life, and families
to feed...

-LV

[Kaleb Pederson]

On Thursday 21 May 2009 03:07:31 pm LudovicoVan wrote:
> > > > On-the-job training on production systems is inefficient at best,
> > > > counter-productive to the business at worst.
> >
> > > This might be true only in theory: as a matter of fact, in most
> > > software factories, people already work over-time, all the time!
> > > (Thanks to incompetent software managers: "permanent emergency" I call
> > > it.) Then, training on-the-job, meant as learning new skills while
> > > going, is in most cases the only option.
> >
> > The fact that people already work a lot of over-time is a problem. It isn't
> > just because of 'incompetent managers;' that is an excuse we make. We choose
> > to do it. We choose to allow it to happen.
>
> I cannot agree on that: it's not the developer's choice, it's rather
> their permanent hell. Not only, as a developer, you have no authority
> to really question decisions taken without even consulting you,
> moreover, and not to forget: even developers have a life, and families
> to feed...

Neither practice nor the job define the craftsman. If a person has a job that does not allow him direct time to study or "practice" and who has no time outside of work to practice, but who nonetheless works to the best of his ability, given the context of his surrounding environment, to improve his skill and code, is he not a craftsman?

All the qualities that we associate with a craftsman -- design, testing, collaboration, practice, etc. are important, but I don't think the lack thereof in any way implies that somebody is not a craftsman. Rather, it's the underlying attitude of the individual. If I were required to classify an individual as a craftsman or not, I think I would measure one thing -- purposeful self improvement.

The number of craftsmanship-like practices and attributes a person has may serve as a rough indicator of how fast somebody might attain the skills necessary to be an expert "craftsman."

This, however, brings up another quandry. Is somebody who, by talent or prior effort has the skills that make him better than 95% of all others, is he still a craftsman if he no longer cares to improve himself nor use his skills to the fullest?

--Kaleb

[Raoul Duke]

> This, however, brings up another quandry. Is somebody who, by talent or prior effort has the skills that make him better than 95% of all others, is he still a craftsman if he no longer cares to improve himself nor use his skills to the fullest?

hey, i think national geographic says, isn't that when the younglings
have to kill him and eat him?

[kelly french]

This, however, brings up another quandry. Is somebody who, by talent or prior effort has the skills that make him better than 95% of all others, is he still a craftsman if he no longer cares to improve himself nor use his skills to the fullest?

This is a point that I've explored a lot over the years.  The question I would ask is "How can you tell good developers from the 'settlers'.  You know the type, they only want to know what they need to know to get them through their 9-5 job.

The desire is what I've identified as the key trait.  It's no different from athetics.  My karate sensei had a student that had natural talent but didn't care and wouldn't work at it.  Another student who was awkward and weak but never quit was much more respected by sensei.  Why would it be any different for a codewright?

codewright.blogspot.com

[Dave Hoover]

On Thu, May 21, 2009 at 5:43 PM, Kaleb Pederson
<kaleb.p...@gmail.com> wrote:
>
> Neither practice nor the job define the craftsman.

I agree. Ongoing long-term successful deliveries define the craftsman.
One's portfolio is what one's reputation is built on. Additionally,
peers and mentors and apprentices can point to your progress and
influence in your communities of practice.

> If a person has a job that does not allow him direct time to study or "practice" and who
> has no time outside of work to practice, but who nonetheless works to the best of his
> ability, given the context of his surrounding environment, to improve his skill and code,
> is he not a craftsman?

Unless you're constantly working overtime or have some long-term
crises going on at home, I don't believe it's possible to have "no
time outside of work to practice". It's simply a matter of
priorities. For example, I started learning to program when I was 26.
I was married, had a 2-year-old at home, and my wife was pregnant
with our second child. I was (and still am) very busy from 6AM to
10PM, 7 days a week. But I did 2 things to allow myself to progress
as a craftsman during my "apprenticeship" years: 1) I refused to work
overtime, and 2) I usually slept about 4 hours a night. I know that's
not sustainable, I make sure I get about 8 hours of sleep nowadays.
But sleep was the sacrifice I was willing to make to give myself the
time to read and code as much as I needed to get to where I wanted to
be. More about my story at
http://blog.nexwerk.com/2009/05/21/dave-hoover-talks-about-my-apprenticeship-years/

> All the qualities that we associate with a craftsman -- design, testing, collaboration,
> practice, etc. are important, but I don't think the lack thereof in any way implies that
> somebody is not a craftsman.  Rather, it's the underlying attitude of the individual.  If
> I were required to classify an individual as a craftsman or not, I think I would
> measure one thing -- purposeful self improvement.

Self-improvement is important, but it's an (ongoing) means to an end.
A craftsman is not defined by attitude, a craftsman is defined by a
portfolio of successful projects. Self-improvement and attitude will
facilitate successful collaborations and project deliveries over the
course of decades.

> This, however, brings up another quandry. Is somebody who, by talent or prior effort
> has the skills that make him better than 95% of all others, is he still a craftsman if
> he no longer cares to improve himself nor use his skills to the fullest?

I think the more important question is, who cares if that guy is a
craftsman? It's sort of like asking if a team is agile. It seriously
doesn't matter if they are agile. What matters is if they are
delivering value to their customers frequently and consistently over
months and years. I see software craftsmanship as a way of
approaching one's career as a software developer. I don't find it
helpful as a way of classifying people.

[Anthony Broad-Crawford]

Sent from my iPhone

+1

> More about my story at
> http://blog.nexwerk.com/2009/05/21/dave-hoover-talks-about-my-apprenticeship-years/
>





>> All the qualities that we associate with a craftsman -- design,
>> testing, collaboration,
>> practice, etc. are important, but I don't think the lack thereof in
>> any way implies that
>> somebody is not a craftsman. Rather, it's the underlying attitude
>> of the individual. If
>> I were required to classify an individual as a craftsman or not, I
>> think I would
>> measure one thing -- purposeful self improvement.

+1

>>
>
> Self-improvement is important, but it's an (ongoing) means to an end.
> A craftsman is not defined by attitude, a craftsman is defined by a
> portfolio of successful projects. Self-improvement and attitude will
> facilitate successful collaborations and project deliveries over the
> course of decades.
>
>> This, however, brings up another quandry. Is somebody who, by
>> talent or prior effort
>> has the skills that make him better than 95% of all others, is he
>> still a craftsman if
>> he no longer cares to improve himself nor use his skills to the
>> fullest?
>
> I think the more important question is, who cares if that guy is a
> craftsman? It's sort of like asking if a team is agile. It seriously
> doesn't matter if they are agile. What matters is if they are
> delivering value to their customers frequently and consistently over
> months and years.

+1

[eco...@gmail.com]

As Ade pointed out in his excellent seminar work is not practice.
Practice is a focused and measurable exercise that is targeted to make
you improve in one area. This exercises form your toolbox to
improvement in your skills. The work you do at work builds upon
experience, you "see things" that at a later moment, if you took the
time to reflect on them (personal retrospectives), you can fall back
to to make the right decision for the moment.

>
>
>> All the qualities that we associate with a craftsman -- design,
>> testing, collaboration,
>> practice, etc. are important, but I don't think the lack thereof in
>> any way implies that
>> somebody is not a craftsman. Rather, it's the underlying attitude
>> of the individual. If
>> I were required to classify an individual as a craftsman or not, I
>> think I would
>> measure one thing -- purposeful self improvement.
>
> Self-improvement is important, but it's an (ongoing) means to an end.
> A craftsman is not defined by attitude, a craftsman is defined by a
> portfolio of successful projects. Self-improvement and attitude will
> facilitate successful collaborations and project deliveries over the
> course of decades.

This is actually something that has been nagging on me for quite a
while. Whereas I believe that constant practice is one of the
cornerstones of a software craftsman, it is just one of them.

If I take a closer look at the manifesto that we put together (at
least it's current incarnation) the last sentence comes into mind:

Not only customer collaboration, but also productive partnerships

This sentence actually distills very much the importance for us, as
software craftsmen, our customers have.

In the early years of a craftsman, the apprenticeship, the main focus
is on the technical skills. The main aim is to create a solid
foundation upon which the craftsman can build in the future. When the
craftsman becomes a journeyman, it is time to take care of a project,
from the initial phase, where the ideas sprout till the point it is
delivered and has to be maintained. But it is in this time of the
journey when the journeyman sees or recognizes that he/she has to act
a little bit more as a business person. Customers become partners, we
need to negotiate and talk to them, no longer protected by our mentors
(at least not 100% of the time). Beyond that, I'll let the masters
talk ;)

I guess that what defines a craftsman depends on where she/he is on
her/his journey...

Software craftsmanship is not about the code only, for me it is a
tension between our principles (ethics), our technical excellence (or
at least the will to get there through deliberate practice honing our
skills) and a business like aspect.

This looks very much like Kent Beck's stool analogy. There are three
legs on a stool, if one is brittle the stool will eventually break
when you sit down on it.

>
>
>> This, however, brings up another quandry. Is somebody who, by
>> talent or prior effort
>> has the skills that make him better than 95% of all others, is he
>> still a craftsman if
>> he no longer cares to improve himself nor use his skills to the
>> fullest?
>
> I think the more important question is, who cares if that guy is a
> craftsman? It's sort of like asking if a team is agile. It seriously
> doesn't matter if they are agile. What matters is if they are
> delivering value to their customers frequently and consistently over
> months and years. I see software craftsmanship as a way of
> approaching one's career as a software developer. I don't find it
> helpful as a way of classifying people.

I totally agree on that. It is a nice ice breaker when talking to
people, but it is just a token, a name. What really matters to the
customer is what this self proclaimed craftsman does, how software is
delivered, and if the relationship is healthy...

>
>
> >

[Dave Hoover]

On Fri, May 22, 2009 at 3:00 AM, <eco...@gmail.com> wrote:
>
> I guess that what defines a craftsman depends on where she/he is on
> her/his journey...

I think that is a very good point. Naturally, at the beginning of
one's journey, there's no portfolio, no set of projects to point at
yet. Your focus should be to build the skills and relationships that
will allow you to start creating that portfolio of successful
collaborations. These are the apprenticeship years. Whether that
focus defines you as a "craftsman" or is a sign that you're an
"aspiring craftsman" doesn't really matter to me. The direction is
the critical thing.

[Kaleb Pederson]

On Thursday 21 May 2009 06:37:58 pm Dave Hoover wrote:
>
> On Thu, May 21, 2009 at 5:43 PM, Kaleb Pederson
> <kaleb.p...@gmail.com> wrote:
> >
> > Neither practice nor the job define the craftsman.
>
> I agree. Ongoing long-term successful deliveries define the craftsman.
> One's portfolio is what one's reputation is built on. Additionally,
> peers and mentors and apprentices can point to your progress and
> influence in your communities of practice.
>
> > If a person has a job that does not allow him direct time to study or "practice" and who
> > has no time outside of work to practice, but who nonetheless works to the best of his
> > ability, given the context of his surrounding environment, to improve his skill and code,
> > is he not a craftsman?
>
> Unless you're constantly working overtime or have some long-term
> crises going on at home, I don't believe it's possible to have "no
> time outside of work to practice". It's simply a matter of
> priorities.

Well qualified. It's almost always about priorities. I know a lot of people who say they don't have time, yet they seem to fit in over 12 hours of television a week.

> > All the qualities that we associate with a craftsman -- design, testing, collaboration,
> > practice, etc. are important, but I don't think the lack thereof in any way implies that
> > somebody is not a craftsman. Rather, it's the underlying attitude of the individual. If
> > I were required to classify an individual as a craftsman or not, I think I would
> > measure one thing -- purposeful self improvement.
>
> Self-improvement is important, but it's an (ongoing) means to an end.
> A craftsman is not defined by attitude, a craftsman is defined by a
> portfolio of successful projects.

Hmm... By the dictionary definition this seems exactly right, but it also seems somewhat different than what is often presented as a craftsman in the arena of software development.

> Self-improvement and attitude will
> facilitate successful collaborations and project deliveries over the
> course of decades.
>
> > This, however, brings up another quandry. Is somebody who, by talent or prior effort
> > has the skills that make him better than 95% of all others, is he still a craftsman if
> > he no longer cares to improve himself nor use his skills to the fullest?
>
> I think the more important question is, who cares if that guy is a
> craftsman? It's sort of like asking if a team is agile. It seriously
> doesn't matter if they are agile. What matters is if they are
> delivering value to their customers frequently and consistently over
> months and years. I see software craftsmanship as a way of
> approaching one's career as a software developer. I don't find it
> helpful as a way of classifying people.

Good point.

Thanks for your thoughts and reflections.

--Kaleb

[Kaleb Pederson]

On Friday 22 May 2009 03:23:16 am Dave Hoover wrote:
> On Fri, May 22, 2009 at 3:00 AM, <eco...@gmail.com> wrote:
> >
> > I guess that what defines a craftsman depends on where she/he is on
> > her/his journey...
>
> I think that is a very good point.

Yes, it's an excellent point.

> Naturally, at the beginning of
> one's journey, there's no portfolio, no set of projects to point at
> yet. Your focus should be to build the skills and relationships that
> will allow you to start creating that portfolio of successful
> collaborations. These are the apprenticeship years. Whether that
> focus defines you as a "craftsman" or is a sign that you're an
> "aspiring craftsman" doesn't really matter to me. The direction is
> the critical thing.

I think this what I was trying to point out when I said "purposeful self improvement." But when I said it, I hadn't thought of any distinctions between the phases of becoming a craftsman.

--Kaleb