Boy Scout Rule Corollary?

[Francesco Rizzi]

Hey everyone. I was catching up on past email threads and some talk about the Boy Scout Rule (BSR) prompted a little click over here...

BSR: "Leave the campground cleaner than you found it"
Thus, we shall try and leave the field in a better shape than we found it. Perhaps we won't be able to make a prime reserve out of it the first time we go there, but over time our effort will make the place a better place.

Isn't there a 'meta rule' at work here? As the number of people that get in the specific field grows (i.e.: number of developers in the team), we should try and spread the idea and spirit of the Boy Scout Rule among them. Otherwise you run the risk of a large number of Inconsiderate Tourists (i.e.: people not adhering to the BSR) nullifying the effort of the Boy Scouts. Depending on the size of the team (number of people that can check in), this becomes more and more critical.

So, I propose a 'corollary' to the Boy Scout Rule:
"Leave your team with one more Boy Scout than you found"

("Leave" and "found" are meant to follow from the basic form of the BSR. YOu may interpret this as the time you join/leave the team, the time you start/end a visit to a team you are consulting, the time you join/leave your office every day, ... )

F.

[Lance Walton]

I agree with the principle. A problem would be agreeing on what
'cleaner' means. As a matter of interest, what do people in this group
value (and if you can state it with numbers, that would be good).

For example, in Java, I like:

Business domain model classes with business domain model behaviour
Small methods:
<=6 lines of code including declaration and closing bracket
cyclomatic complexity generally not bigger than 2, and definitely not
bigger than 3
number of parameters <= 4 (and elimination of data clumps is a high
priority)
Small classes:
number of fields no more than about 4 or 5 (generally)
not bothered by the number of methods as long as they are cohesive
but generally find that when sum of cyclomatic complexities > about
40, some splitting up can be done
efferent couplings no bigger than about 25, including coupling to
'system' classes
Small packages:
I generally find one or two public classes supported by a few package
visible classes works well
Package naming is important (http://www.stateofflow.com/journal/68/brown-paper-packages-tied-up-with-string
)

When I come across stuff that doesn't conform to these kinds of
things, I feel an itch.

However, I've found that other people I work with follow rules like
'if a method is only use by one other method, inline it', which I find
astonishing. Clearly this creates tensions because their idea of
'cleaner' is not the same as mine.

Regards,

Lance

-----
Lance Walton
http://www.stateofflow.com
http://homepage.mac.com/LanceWalton

[Francesco Rizzi]

Lance,
I think the Boy Scout Rule (among others) is intentionally vague on certain aspects. These are guidelines, principles to adhere to. It is difficult enough to define them, share them and internalize them as they are... with more details they'd become un-bearable I fear.

In this case, the focal point is to try and improve the code.
What it means for the code to be 'better' ('cleaner', whatever term we want to use to indicate a directed line from 'bad' to 'good') is clearly a huge topic of its own and is left outside the scope of this specific Rule.

I think your argument points to a possible issue with the BSR itself though.
Without agreement on what it means for the 'campground to be cleaner', different Boy Scouts might be working in different directions and actually 'against each other' ("It is always about the people", isn't it?). That might be the limit of the BSR metaphor. It doesn't make the metaphor bad, but it indicates we should find a new metaphor that can overcome that limit. Until then, we can use the BSR with awareness of its limitations.

How do Boy Scouts define what it means for a campground to be "cleaner" ?

F.

[gustin]

The Boy Scout ethics, law, and motto resonates with me. I am an Eagle Scout (didn't participate much after 13 years old), but the ethics I was exposed to in Boy Scouts at a young age really helped shaped my life and my worldview around how to treat people and conduct my business.

A Scout is trustworthy, loyal, helpful, friendly, brave, clean, and reverent. The Scout Law and motto is at the core of what the program revolves around and they are constantly reviewed and returned to. 

I think it is a good example of how an organization can instill a sense of principle through example and practice. If the core set of principles of the software craft can be embodied by this group and held to, it would be more then a success if we can help instill the sense of quality software in others. 

The definition of "brave" in the Scout Law could be interpreted in different ways, and I think some of the software craft principles are similarly subjective. I think it is more of the spirit of honoring the craft that people will resonate with.

The principles should be abstract enough that people can embody and form their own internal meaning of value, but clear enough that it can't be skewed and used to form a negative practice. 

~)o

gustin

--
  . . : entryway : . .
software development
   www.entryway.net
     888-595-4227


      Gustin Prudner
  office: 540.745.5279
    cell: 540.449.2700
    fax: 540-301-0738

[Dave Hoover]

On Fri, Apr 10, 2009 at 7:43 AM, Francesco Rizzi
<frances...@gmail.com> wrote:
> So, I propose a 'corollary' to the Boy Scout Rule:
> "Leave your team with one more Boy Scout than you found"

I think this is an excellent corollary, particularly for people
working in difficult corporate environments. And it works for people
like Uncle Bob as well as an inexperienced yet passionate young
developer.

[Lance Walton]

What would happen if we don't try to find a better metaphor and instead just state what we think 'cleaner' code means?

[Dave Smith]

On Fri, Apr 10, 2009 at 6:53 AM, Francesco Rizzi <frances...@gmail.com> wrote:

How do Boy Scouts define what it means for a campground to be "cleaner" ?

From several years of practicing this as a Scout, the need to have discussions over definitions never came up. We almost always came in to a campsite that hadn't been left clean by prior campers. By simply following a practice of cleaning up all visible litter, "cleaner" was pretty much guaranteed. "Clean" was the real standard, which in practice almost always meant "cleaner". In retrospect, I think that phrasing the rule as "cleaner" was a way of signaling to the tribe that we had set a "higher standard". Part of scouting is raising the bar on standards across a number of aspects of one's life.

I've moved away from using the Scout campsite analogy as I find fewer and few people who've ever camped. "Leave a clean kitchen" seems to resonate better now. (http://www.davewsmith.com/blog/?p=171).

Dave

[Lance Walton]

Whether it's a campsite or a kitchen, nobody could say that adding another dirty dish / throwing a piece of litter on the floor would make it cleaner. In code, we seem to have precisely that issue.

I think we can all agree, without appeal to metaphor or meta-discourse, that we'd like to leave a codebase cleaner. But rather than finding another analogy / metaphor / simile, and without replacing the word 'cleaner' with another equally abstract term (such as 'more maintainable')  what do people mean by 'cleaner'?

As well as the metrics I suggested earlier (which are nowhere near enough on their own), we could say that the codebase (or the little part that we've worked on recently):

is a little closer to the SOLID principles (quite an abstract statement in itself actually)

that we've reduced the number of Demeter violations

that we've recognised that in a particular class, there was a lot of behaviour associated with a single field, so we extracted a new class that has that field and all of it's associated behaviour, thus increasing cohesion, semantic level and degree of abstraction

that we reduced the visibilities of some methods and classes

that we reduced feature envy by moving behaviour into it's appropriate class

etc.

But this is me. What do other people on this list mean by 'cleaner'?

The reason I'm pushing this is that a lot of the discussion in this group has been quite abstract. I'm a big fan of abstraction. Why? Because it suppresses details. But we need details here.

At the recent Software Craftsmanship conference in London, during one of the sessions, one of the speakers talked about method length, and the question was posed 'how long is OK for a method'. At least one person thought that 'no more than a screenful' is OK. If I see a method that long, I generally feel sick (there are exceptions). However, I'm, aware that some people find my focus on much smaller methods (and in fact my classes are often no bigger than a screenful) difficult to deal with.

I frequently have classes that wrap a single field. Others find that to be an extra class that violates one of XP's notions of 'simplicity'.

In short, we can probably all agree on a principle of cleanliness. But should we try to work together, I'm sure that some of us would mutually be driven round the bend by some others because of the difference in the implementation of that principle. I am therefore truly interested in very concrete expressions of what people mean by 'clean'.

Regards,

Lance

-----

Lance Walton

http://www.stateofflow.com

http://homepage.mac.com/LanceWalton

[Adewale Oshineye]

2009/4/10 Lance Walton <lance...@mac.com>:

Lance,
What you're describing seems to be what the C2 wiki calls Ravioli
Code: http://c2.com/cgi/wiki?RavioliCode
This can be a good thing as long as we're not abiding by arbitrary
line length limits and we're conscious of the fact that in some
domains breaking things into very small methods makes it harder for
others to understand your intentions. Another situation where very
small methods make code to understand is when you're implementing
well-known algorithms or processes.

I tend to use the heuristic: make things as small as possible by
continually extracting meaningful chunks and giving them
intention-revealing names. If making something smaller obscures my
intention (for instance because I can't think of a good name for the
small chunk) I'll leave it alone. Sometimes that may involve leaving
behind a very long comment explaining the issues. Sometimes the act of
writing that comment will clarify my intention and I can actually
extract the chunk. When that doesn't happen I'm quite willing to trust
that someone in my team will see what I've missed and improve on my
work.

I'm also quite happy with the notion that a team converges on a sense
of "better" that makes sense for them. I suppose that's because I'm a
little suspicious of ideals like "cleaner" that don't acknowledge that
there are trade-offs involved. For instance in Python you can
sometimes get into situations where the overhead of polymorphic method
dispatch makes your code unacceptably slow and you have to do
something uglier instead. Or the overhead of object creation means
your code can't handle the dataset you have and you're forced to use
things like named tuples which obscure your intent but radically
reduce your memory footprint.

I'd like to hear more from people on situations where they've had to
make these kinds of trade-offs or discovered that their
rules/metarules were actually heuristics.

[Lance Walton]

The term 'Ravioli Code' predates the mother wiki, I think.

I'm well aware of the tradeoffs.

A team can't converge unless the individuals each start from some
position. I want to know what that position is. I want to see the
spectrum.

I want to know what is important to people. Without metaphor. And
without people talking to me as if I'm naive, inexperienced or unaware.

Regards,

Lance

[Raoul Duke]

> But this is me. What do other people on this list mean by 'cleaner'?

it could be curious fun if there were a poll set up with a bunch of
multiple choice questions along these lines. not that i am nice enough
to get around to doing that, i'm smart enough to know i won't since i
have little free time :-}

sincerely.

[Michael Hunger]

That also resonates with the values of XP.
Communication, Feedback, Simplicity, Courage and Respect.

I think the way from bad code to better code is no straight line but a big territory with many ways, pitfalls canyons
and shortcuts etc.

But resonating with the values above I'd like the values that kent beck based his "Implementation Pattterns" (although
I'm very ambivalent about the whole book) on.

Code quality is measured in (in this order): understandability/readability, simplicity, flexibility.

That makes any code that improved in one of the areas above (preferably in the first two) better than before.

Michael

--
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)

[Michael Hunger]

This "higher standard" also resonates with the quote from Christopher Alexander from the foreword of Tales of Software
Development by Dick Gabriel that I posted to the list before.

In my life as an architect, I find that the single thing which inhibits young pro-
fessionals, new students most severely, is their acceptance of standards that are too
low.If I ask a student whether her design is as good as Chartres, she often smiles
tolerantly at me as if to say, “Of course not, that isn’t what I am trying to do. . . . I
could never do that.”
Then, I express my disagreement, and tell her: “That standard must be our
standard. If you are going to be a builder, no other standard is worthwhile. That is
what I expect of myself in my own buildings, and it is what I expect of my stu-
dents.” Gradually, I show the students that they have a right to ask this of them-
selves, and must ask this of themselves. Once that level of standard is in their
minds, they will be able to figure out, for themselves, how to do better, how to
make something that is as profound as that.


!!!!!
Two things emanate from this changed standard. First, the work becomes
more fun. It is deeper, it never gets tiresome or boring, because one can never
really attain this standard. One’s work becomes a lifelong work, and one keeps
trying and trying. So it becomes very fulfilling, to live in the light of a goal like
this.
But secondly, it does change what people are trying to do. It takes away from
them the everyday, lower-level aspiration that is purely technical in nature, (and
which we have come to accept) and replaces it with something deep, which will
make a real difference to all of us that inhabit the earth.
!!!!!!!!!!

[Michael Hunger]

What about just the code smells from the "Refactoring" book ?

They are easy to grasp, quite expressive and widely applicable:
From http://c2.com/cgi/wiki?CodeSmell

DuplicatedCode - See: OnceAndOnlyOnce, SwitchStatementsSmell
Methods too big - See: ComposedMethod, TallerThanMe, LongMethodSmell
Classes with too many instance variables - See: ExtractComponent?, ValueObject, and WholeValue
Classes with too much code - See: OneResponsibilityRule, GodClass
Strikingly similar subclasses - See: BehaviorToState
ParallelInheritanceHierarchies - Violates OnceAndOnlyOnce.
An instance variable that is only set in some circumstances
Comparing variables to null - See: NullObject, NullConsideredHarmful
Too many private (or protected) methods - MethodsShouldBePublic.
FeatureEnvy, many messages to the same object from the same method - See: MoveMethod.
VerbSubject construction - See: MoveMethod
ExcessiveOverloading - this probably like VerbSubject construction - See: MoveMethod
SameNameDifferentMeaning
ExpensiveSetUpSmell - As in the "setUp()" of JavaUnit.
WithBlocks (WithBlockCodeSmell) - ExtractMethod to the object the code is acting on. (Or encapsulate the data or 3rd
party object in an object you control and can add methods to.)
Code not actually ever used - see: YouDontNeedItAnymore
Trivial modules or layers - they only call the next layer down
InstanceofInConditionals
Similar looking code sections that vary only a few percent - CodeGenerationIsaDesignSmell unless it's
ActiveCodeGeneration, in which case it's a valid workaround for a LanguageSmell.
etc..

Michael

[Michael Hunger]

Recently I had a discussion with a fellow craftsman (Steffen Gemkow, objectfab, translator of Pragmatic Programmer into
German) about coding styles.

I personally prefer a very concise coding style with guard clauses which return early, single level of abstraction
within a method. Almost no nested blocks (returning as soon as it becomes clear this path is done), to keep the ballast
of the mental model as small as possible when understanding code (that is also quite nicely explained in Implementation
patterns), extracting methods with descriptive names rather than writing comments, narrowing the scope of variables and
methos as much as possible, having final method params, local and instance variables etc. So keeping it as concise and
"simple (for me)" as possible. I'm also very fond of refactoring code as I have the best tools available for the job
(experience and IntelliJ).

He argued that he moved away from this concise style some years ago as he evolved his development skills. The problem is
when you're writing this kind of code, many developers have a harder time understanding it, and even worse when copying
it they make a lot of mistakes and produce crap (e.g. by leaving/forgetting out important alternative paths). So he
simplified his coding style by:
* declare every local variable you'd like to use upfront
* have ony one exit point from a method with a commonly named variable (result)
* each if needs an else / or comment // no else, why
* no final keywords as it clutters the code

His point is to find the common denomiator for a team where the majority of people can understand, maintain and extend
the code and is able to keep developing sound code with a single style.

I can understand his motivation and the problems it solves and have also experienced sometimes people who complained
about my many little methods, classes and scopes (they rather like big classes and big methods where they can see
everything at a single glance).

What do you all think about that?

Michael

[Lance Walton]

Let's take the first one on that list. Does everybody here always
remove all duplicate code? Or is it sometimes 'pragmatic' or a sign of
superior craftsmanship to leave some duplication?

Where's the boundary? All knobs to 10, or does a craftsman know that 9
is best sometimes? Do we all have the same definition of 'sometimes'?

I'm not trying to be difficult. I am not looking for prescriptions; I
know we have to balance some stuff (but I do not believe that
everything is subject to context). But my experience has been that so
many people apparently agree on the principles when they talk,
particularly when that talking is at a sufficiently abstract level,
but the application of those principles rapidly shows that the parties
were talking about completely different things or have completely
different interpretations of the principle.

[Lance Walton]

Thankyou for being so concrete.

I agree with your style.
I disagree strongly with every part of your friend's style and his
reason for doing it.

There it is :-)

Lance
-----
Lance Walton
http://www.stateofflow.com
http://homepage.mac.com/LanceWalton

[Michael Hunger]

Could you elaborate on that?

A while ago I found an interesting approach on Code Reviews called "tick the code" at
http://www.tick-the-code.com/en/index.php

It is a quite fast but imho limited application of fixed rules (one at a time) to a printout of the code to be reviewed.

There I also found the "single exit point" and "no if without else" rules which made me discuss that with the author and
one of my friends and the pragprog mailing list. It seemed I was quite alone with my approach back then :)

But I have found the minimizing of mental ballast when reading code (not keeping in mind all the open scopes, paths,
used or to be used variables, conditions that were evaluated for one path etc) in mind while reading code is more
beneficial than the consistency of having the same structure over and over again.

[Michael Hunger]

One thing I found quite helpful when dealing with bad code and improving (deleting, refactoring, discussing) it, was to
communicate the problems I found visually.
For some time (3 or 4 year) I'm a big fan of demotivators (despair.com). So I started creating (de)motivators for code
smell (and other stuff) I found in my projects and collected them.

http://jexp.de/index.php?n=Info.Demotivators

We print them out and hang them in the office to remind people of doing better and having a pointer when finding stuff
like that again - just point to the poster and either say "rembember?" or "read this".

HTH

Michael

[Raoul Duke]

some random thoughts for me, the things i think make sense to me for
craftsmanship:

* smaller is better when possible
* less nested is better when possible
* names are important and really hard to get right (a very good thing
for pairing or code review)
* i prefer one return since it makes maintenance easier, over
test-return-test-return style
* languages that don't support "let" or "where" really really irk me
because they have lost a really nice optional middle ground between
one-long-method vs. lots-of-little-methods.
* i would like to see user defined types used more, vs. primitives
since i feel the latter are insufficiently constraining / expressive
(obviously i'm talking about typed languages :-)
* i prefer typed languages that have type inference
* inheritance is, generally, evil
* i prefer pure fp over other things, but realize (see CTM by Van Roy
+ Haridi) that state change will be inevitable, and so things like OO
or STM or Agents will be needed -- but i think one should use
shared-mutable-state as a last worst resort in some sense (not that
STM etc. are perfect themselves by any means).
* on the whole i don't like whitespace sensitive languages for bigger
code if only because my IDE can't automatically reformat it
* c++ is evil ;-)
* java sucks ;-)
* ok, ok, really, "it depends".

p.s.: my on-going brain dump of concerns:
http://therightabstractions.wikispaces.com, in particular
http://therightabstractions.wikispaces.com/ToolsAndProcess.

sincerely.

[Raoul Duke]

> http://jexp.de/index.php?n=Info.Demotivators

hysterical. excellent!

[Scot Mcphee]

Hello,

I am new to this list. I found this discussion interesting so far,
just wanted to add my 2 cents.

First I want to say that generally I agree with Lance in that I think
methods should be small, as small as possible. Maybe I should add "but
no smaller". I've found that some developers are often shocked when I
tell them that I think the ideal for a method is about five lines,
including the declaration.

However, I note that I say "ideal". Ideals are human impossibilities.
No human is ideal. I don't really want to get bogged down in that.
Suffice to say that holding humans (and their artefacts) up to some
impossible ideal only leads one to reject the failing humans. So, is
this ideal impossible? In some cases. But that does not mean we
shouldn't strive to get there. I can't be a perfect human in any
respect but I can try to be a *better* one. And so can my code.

But enough of the motherhood and generalities;

On 11/04/2009, at 07:50 , Lance Walton wrote:

> Let's take the first one on that list. Does everybody here always
> remove all duplicate code? Or is it sometimes 'pragmatic' or a sign of
> superior craftsmanship to leave some duplication?

Yes, I would always strive to remove duplicate code where I found it.

The only thing that would stop me is if I was ordered not to by some
superior force, e.g. as a consultant on a one-week or other similarly
short engagement to get something specific done, and the client told
me not to bother (assuming they found out before I did anything). I
would then spend the time I would have spent doing the fix writing the
client an email and telling them to confirm in writing they don't want
me to attend to any major code-quality issues.

> Where's the boundary? All knobs to 10, or does a craftsman know that 9
> is best sometimes? Do we all have the same definition of 'sometimes'?

In a previous life - in between electrical engineering and starting
computer science - I was an audio engineer. I still have some interest
in that area. I can fully extend the analogy.

I can certainly tell you that "10" is definitely a "bad setting". At
the end of the knobs there lies non-linearity. Unless you deliberately
choose it as an aesthetic choice (which is perfectly valid, even good
old analogue tape distortion can be very sweet, on some types of
music). Volume knobs definitely shouldn't usually go past about 70% in
a "mainstream" application. I try to never set them beyond 50%. For
equalisation ... "it is better to cut than boost". In fact going as
far back to the original source as you can is the best. Bad guitar
sound? Go into the recording studio, Listen to the guitar. Does it
sound bad in there? Move the microphones, change the microphones,
change the guitar, investigate the guitar's signal chain to the
amplifier, change the amplifier, move everything to a new room or
maybe try the stairwell, do you need to change the player (defer to
producer), and only now, am I looking at the mixing desk, the
outboard, and other signal processing tools. Yet people think, I'm
sitting behind the tracking desk, it should be my first area of
responsibility. Yet it is my last!

In some ways, and I'm going to make a probably unsustainable analogy
here, when I'm sitting in front of my IDE looking at adding
functionality (implementing a story) I'm trying to see what "further
back" in the signal chain needs to be changed, what has to be taken
away, and so on before I even begin to start inserting my new code
into the chain. If I don't find anything that immediately jumps out at
me then I guess I figure I'm right to start writing the unit test for
my new code. In many ways the process is part of my "what existing
unit tests are there"? and "where does my new unit test belong?"
thinking-time that goes into my design decision-making process really
before I even start typing on the keyboard.

So what is the definition of "sometimes"? Well maybe it's part of the
ineffable art of craft, that we all learn when that "sometimes"
occurs? Certainly even with all the "rules" of audio engineering I
stated above there are many creative engineers (much better than me)
who break all those rules and still manage to make beautiful sounding
recordings, because in some part it is about the quality your 'ear'
more than anything else. But I guess that is not being helpful in this
particular context.

> I'm not trying to be difficult. I am not looking for prescriptions; I
> know we have to balance some stuff (but I do not believe that
> everything is subject to context).

Perhaps in this case it's better if we enumerate what we believe those
things that are not contextual to be. Certainly I would say that cut
and paste code duplicates are one such context-free occasion. Also I
would add, any method longer than "a screen" must be made shorter than
"a screen" and ideally, five or six lines if possible. For me it's the
screenful rule (I take that to be 15 to 20 lines) that has the smell
of Inviolate Principle about it. Shorter than that is better, but only
if it *is* "better", i.e. increases code readability /
understandability.

I've written way too much for such little signal of doubtful quality
that I will terminate my ramblings here.

scot.

[Lance Walton]

I will try to elaborate.

> He argued that he moved away from this concise style some years ago
> as he evolved his development skills. The problem is
> when you're writing this kind of code, many developers have a harder
> time understanding it

I would rather work with those that do understand it.
I also don't believe in conforming to the lowest level of skill. I
would rather raise it.

> , and even worse when copying
> it they make a lot of mistakes and produce crap (e.g. by leaving/
> forgetting out important alternative paths).

How do his points prevent the leaving out of alternate paths? Simply
writing a comment for 'no else' situations won't do it. All it might
do is make you think a bit more. After you've done that, you don't
need the comment any more.

Where are the unit / acceptance tests that make sure you haven't left
out paths.

> So he
> simplified his coding style by:

I dispute the term 'simplified' . 'Changed' certainly.

>
> * declare every local variable you'd like to use upfront

I only agree with this if the method is so small (as I like them to
be) that there is nowhere else other than 'upfront' to declare them.
In this case, they tend to be assigned immediately as well and they
are usually explanatory variables (constants actually). I'd prefer to
remove the explanatory variable and introduce an explanatory method
instead because the method is reusable, the value of the calculation
assigned to the variable is not.

>
> * have ony one exit point from a method with a commonly named
> variable (result)

I don't see what the benefit of this is. Combined with the aversion to
'final's it means that you can't tell whether the value of 'result' is
later changed before returning, thus obscuring what the returned value
is.

If your method maintains a consistent level of abstraction, the
pattern of returns will be obvious.

>
> * each if needs an else / or comment // no else, why

Already answered above.

>
> * no final keywords as it clutters the code

What of the clutter in the developer's mind when they have to worry
about reaching definitions. Again though, in methods of only a few
statements it is less relevant, since you literally can see the whole
thing at once.

Also, syntax disappears into the background when people know it well
enough. Semantics does not disappear into the background. The
'clutter' of the word 'final' is syntactical. The effect of it is
semantic. Except when you *have* to do it because of anonymous
classes, in which case it's just a stupid language design choice.

>
>
> His point is to find the common denomiator for a team where the
> majority of people can understand, maintain and extend
> the code and is able to keep developing sound code with a single
> style.

I am not interested in the common denominator (and don't particularly
agree that this 'style' manages it). I have a suspicion that the
distribution of developer skill is bimodal with a significant majority
(90%) of the population around the 'less skilled' mode. I am
interested in the highly skilled minority. I would very much like it
if that minority would grow in proportion and I am certain that the
way to prevent it from doing so is to be accommodating of the majority.

Assuming I am one of the more skilled (which my ego requires I do
assume, even if I do have doubts sometimes), I am happy to help those
of the majority who want to go my way, as I have been and continue to
be helped. Those who don't want to, well I try to avoid them.

We need to raise our expectations, not lower them.

Regards,

Lance

-----
Lance Walton
http://www.stateofflow.com
http://homepage.mac.com/LanceWalton





On 10 Apr 2009, at 23:09, Michael Hunger wrote:

>

[Michael Hunger]

+1 to all of that.

Its pareto again, as so often.

Cheers

Michael

--

[Francesco Rizzi]

Wow. Nice discussion!
I take it that the shift of this thread to the topic of "what makes a campground cleaner?" means everyone agrees to the proposed corollary form the OP?

"Leave your team with more Boy Scouts than you found"
(I applied a small change because there's no reason to limit it to 1 new Boy Scout)

As far as what it means to be "cleaner", I think you are all bringing up great points; the only thing I could add is that the details of "cleanliness" might be different from case to case, and team to team.

For instance: yes, we should always remove duplication. There's no excuse to not doing so in theory. In practice (and a pragmatic eye is still part of our craft) there are cases when we have Extremely Good Reasons for leaving some (hopefully rare and small) duplication behind. The Business Value, the Deadline, the Customers, the Users, the 'other problem in the code' that is much worst and requires immediate attention, these are but a few examples. With infinite resources we could tackle all problems, but -if all other resources can be maximized- time is limited.
These are not 'get out of jail' wildcards to be pulled out of a sleeve when the developers want to 'be lazy', but each of those forces can create a situation where... well.. it's ok to leave those 3 lines of code that are repeated in 2 places.

[I know, the previous paragraph might trigger a big discussion... I hope it is clear I try with all my abilities to avoid those cases, and to remove the duplication whenever I see it]

So, then... for each project, for each team, the conditions are different, and the forces I mentioned above will be applying different pressures in different direction. The bottom line is that for each case, you have a different line marking what is 'acceptable' and what isn't.
The ideal (oh my, those philosophical terms from school are coming back after all!) of 'pure cleanliness' might not shift, but it might also be un-reachable. We should strive for it at each step, but I think it *is* part of our craft to recognize practical limitations, and adjust accordingly. That, I suspect, is why the BSR talks about an abstract term rather than being 100% concrete. I also find interesting that the 'ambiguous' portion of the BSR is the idea of 'cleanliness'. It makes me think that the core of the BSR is not "what it means to be cleaner"; rather.. the BSR is all about "leave it cleaner than you found it", whatever it might mean, in each scenario, to be cleaner.

F.

[Adewale Oshineye]

2009/4/10 Lance Walton <lance...@mac.com>:

>
> The term 'Ravioli Code' predates the mother wiki, I think.
>
> I'm well aware of the tradeoffs.
>
> A team can't converge unless the individuals each start from some
> position. I want to know what that position is. I want to see the
> spectrum.
>
> I want to know what is important to people. Without metaphor. And
> without people talking to me as if I'm naive, inexperienced or unaware.

This last sentence makes me believe I have upset you. If so, how? I
genuinely do want to understand.

You may be well aware of the trade-offs but our discussions here seem
prone to wandering into discussions of ideals and rules rather than
heuristics. In that spirit here are some of my heuristics that I use
when working with object oriented and garbage collected languages:
- Guard blocks
- Multiple returns
- Default assumption that everything is immutable until proven otherwise
- Domain modelling with an understanding that one's understanding of
the domain will change and that certain parts of the domain will
'attract' features and we'll have to watch carefully to make sure they
don't become God-classes just because the ubiquitous language we're
using places them at the heart of everything.
- Using DDD but watching out for the point when an entity should
become an aggregate
- Solving problems with data structures rather than conditional logic
(this can range from using polymorphism rather than conditions all the
way to using a priority deque in order to reduce apparently complexity
in a system. I'm saying apparent complexity because in reality we've
just moved the complexity into the implementation of the data
structure)
- Eliminate cyclic dependencies
- Use Whole Values (from Ward Cunningham's Checks pattern language)
- Treat domain objects as state machines so that the set of legitimate
transitions is carefully controlled/tested/restricted
- Use constructors rather than Sprint/Pico/Guice/etc.

Most of my heuristics are derived from a combination of Beck's 2
Smalltalk books; Arthur Riel's book: Object Oriented Heuristics,
Meilir Page-Jones and the Zen of Python.

[Lance Walton]

I don't buy the distinction between theory and practice. In
programming, there are statements made at one level of abstraction
that need refining at a more concrete level, but this is not a
difference between theory and practice.

For example, is there duplication here (Java):

for (Foo foo : foos) {
foo.bar();
}

for (Foo foo : foos) {
foo.baz();
}

If there is duplication, would you remove it? If not, why not? Would
it make a difference if the old style idioms for iterating over a
collection were used instead of the enhanced for-loop?

What about this?

for (Foo foo : foos) {
if (foo.isSomething()) {
foo.bar();
}
}

for (Foo foo : foos) {
if (foo.isSomething()) {
foo.baz();
}
}

Now is there duplication? Where is it? Would you remove it? etc.

Now some people would say something like 'in theory, I remove all
duplication. In practice the clutter that Java introduces would
prevent me from doing so here.' But that simply avoids a learning
opportunity.

Regards,

Lance

-----
Lance Walton
http://www.stateofflow.com
http://homepage.mac.com/LanceWalton

[Torbjörn Gyllebring]

Most of the time not removing duplication of this sort is a by product
of working with a crude tool. C# (that pays my bills) and Java are
quite similar in that they quickly get very very verbose removing
duplication at this level in thoose languages regreattably often leads
to horrible constructs and a lot of language noise not needed in more
elegant languages.

But abstraction also comes at a price depending on what the real
problem really is anything from assembly through C and onwards to C++,
C# and Haskell could be the right level of abstraction to work at.
Depends on the problem, people and sourroundings :)

[Francesco Rizzi]

On Sat, Apr 11, 2009 at 5:43 AM, Lance Walton <lance...@mac.com> wrote:

I don't buy the distinction between theory and practice. In
programming, there are statements made at one level of abstraction
that need refining at a more concrete level, but this is not a
difference between theory and practice.

For example,

[...]

Now some people would say something like 'in theory, I remove all
duplication. In practice the clutter that Java introduces would
prevent me from doing so here.' But that simply avoids a learning
opportunity.

Good example.. lots to think..
My instinct is to reply that the language used to implement the software is a Strong Force.
It is not a Stakeholder to the project, so it should bend to the will of the Stakeholders. However, it does come with a lot of baggage: it certainly has a limited flexibility, so it needs to be dealt with appropriately.

From the previous 2 or 3 sentences it should be evident that, when we find that the language is leading us down a 'dirty' path, we should try and turn around. We can look for alternative languages, we can look for different ways for us to use the language we picked (e.g.: iterators instead of loops?). If the Stakeholders want to go in one direction, and the programming language leads us a different way, the Stakeholders must win.
This applies to all the tools we use.

Part of our craft is to know the various tools available (is there a different language we could use that leads to less clutter in this scenario?), the trade offs involved, and so on.
One of our responsibilities is to ensure that the tools bend to the will of the Stakeholders, not the other way around. In a sense, our job is exactly to deal with the limitations of the tools used to implement the application, and overcome them in the most desirable way.

How much work would it be to remove the 'clutter' introduced by the language? That's the cost.
The benefit, of course, is that the product would be that much closer to the ideal of 'cleanliness'.
Collaborate with the other Stakeholder and look at Cost vs Benefit.
The Craftsperson inside of you will probably be kicking and screaming by now, since it is instinctively attracted to the Benefit regardless of the Cost.
My opinion is that Craftsmanship can be relevant only if we maintain it in the practical world. In this case, that means telling our Craftsmanship instinct that sometime the Cost does not justify the Benefit, and that the determination of when that is the case should be done by the Stakeholders (not just the developers).
 

F.

[J. B. Rainsberger]

On Fri, Apr 10, 2009 at 14:35, Lance Walton <lance...@mac.com> wrote:

> What would happen if we don't try to find a better metaphor and instead just
> state what we think 'cleaner' code means?

Didn't someone do this a decade ago? I find I get great results from

1. Passes tests
2. Minimizes duplication
3. Maximizes clarity
4. Is small
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice
Register for Agile 2009 at http://www.agileregistration.org

[J. B. Rainsberger]

On Fri, Apr 10, 2009 at 10:00, Lance Walton <lance...@mac.com> wrote:

> However, I've found that other people I work with follow rules like
> 'if a method is only use by one other method, inline it', which I find
> astonishing. Clearly this creates tensions because their idea of
> 'cleaner' is not the same as mine.

We don't need to define good design.
http://www.jbrains.ca/permalink/220

[Kaleb Pederson]

On Fri, Apr 10, 2009 at 2:28 PM, Michael Hunger
<mic...@passionate-developers.org> wrote:
> He argued that he moved away from this concise style some years ago as he evolved his development skills. The problem is
> when you're writing this kind of code, many developers have a harder time understanding it, and even worse when copying
> it they make a lot of mistakes and produce crap (e.g. by leaving/forgetting out important alternative paths).

My goal, as a developer, is to write the absolute best code I can, at
the time. William Strunk of the /Elements of Style/ states:

"Vigurous writing is concise. A sentence should contain no
unnecessary words, a paragraph no unnecessary sentences, for the same
reason that a drawing should have no unnecessary lines and a machine
no unnecessary parts. This requires not that the writer make all
sentences short or avoid all detail and treat subjects only in
outline, but that every word tell."

Our choice of words should ultimately depend on our audience. I'm not
going to write identically for elementary school students and
university graduates. To substitute unnecessary syntax or structure
when a more telling option is available seems wasteful.

To curtly describe my first reaction, the above sounds like dumbing
down the curriculum because the students don't want to take the effort
to learn. This might be the correct thing to do, for him. If an
employer can't keep employees long enough to adequeately train them or
doesn't hire those who will take the effort to learn, than it may be
the his best option. But if that were the case, I'd hope the company
would evaluate its tenets and practices and make necessary changes.

I'm a developer, and developing is a craft. I'm also a writer. I
write code. Unless my audience deserves otherwise, I'm going to use
the best and most descriptive syntax, structure, adjectives and
adverbs I can muster. I want my kids to ask questions. I want other
developers to ask questions. I want to learn.

--Kaleb

[Robert Martin]

I heard today from someone that the software craftsmanship movement has adopted a secessionist attitude.  Specifically they said that the folks involved have decided to move to boutique shops because they can't be craftsmen in corporate IT.  This harkens back to Martin Fowler's famous dipole: "Change your organization or change your organization."  

My view is that a professional simply does the best job possible in the environment where they work.  If you are in corporate IT, you do the best job you can there.  If you are in a boutique, you do the best job you can do there.  Moving from one to the other does not necessarily make you a craftsman.  Indeed, there is something to be said for doing it where its *hard* as opposed to where it's easy.  Which is the greater craftsman: the one who can hold his/her disciplines under adversity, or the one who faces no adversity?

In any case, secessionism is the wrong attitude.  Our goal ought to be "change from within" not "revolution".  

----

Robert C. Martin (Uncle Bob)  | email: uncl...@objectmentor.com

Object Mentor Inc.            | blog:  blog.objectmentor.com

The Agile Transition Experts  | web:   www.objectmentor.com

800-338-6716                  | twitter: unclebobmartin

[Mark Nijhof]

I agree that changing workplace is not making any difference in you
being a Craftsman or not, but changing a workplace can (in my eyes)
definitely help you to become a better Craftsman. With that I mean
that as a Craftsman you want to constantly improve and learn, this is
not possible in all workplaces, then you would of course do this in
your own time as well, but if you cannot practice your new learned
knowledge you cannot really say you understand the implications. An
other thing is that if you are the main (or one of) driving sources
for improvement in your workplace then that means that you will not
have a more senior (master) person above you from whom you can learn.
And finally changing a current situation where the other people don't
really see the need or are not really willing to learn can be really
exhausting and demotivating.

So I think changing workplaces can make a positive difference in your
own progression towards becoming a better Craftsman, and personally I
would welcome an opportunity to work with more knowledgeable Craftsmen
above trying (and I am trying) to improve the current workplace I work
in.

-Mark

[Jason Gorman]

A very interesting point. I'm seeing a whole variety of ways of
working, learning and sharing.

I think maybe there's nothing necessarily wrong with boutiques as long
as they're not islands unto themselves. The reality seems to be - at
least here in London - that there is a strong community of maybe a
thousand or so developers working in all kinds of circumstances, but
who are learning and sharing with each other in their own time and off
their own backs.

Jason Gorman
Agile Boutique Craftsman & Lion Tamer
www.codemanship.com

On Apr 13, 7:06 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> I heard today from someone that the software craftsmanship movement  
> has adopted a secessionist attitude.  Specifically they said that the  
> folks involved have decided to move to boutique shops because they  
> can't be craftsmen in corporate IT.  This harkens back to Martin  
> Fowler's famous dipole: "Change your organization or change your  
> organization."
>
> My view is that a professional simply does the best job possible in  
> the environment where they work.  If you are in corporate IT, you do  
> the best job you can there.  If you are in a boutique, you do the best  
> job you can do there.  Moving from one to the other does not  
> necessarily make you a craftsman.  Indeed, there is something to be  
> said for doing it where its *hard* as opposed to where it's easy.  
> Which is the greater craftsman: the one who can hold his/her  
> disciplines under adversity, or the one who faces no adversity?
>
> In any case, secessionism is the wrong attitude.  Our goal ought to be  
> "change from within" not "revolution".
>
> ----

> Robert C. Martin (Uncle Bob)  | email: uncle...@objectmentor.com

[Raoul Duke]

hi,

> My view is that a professional simply does the best job possible in the
> environment where they work.

> In any case, secessionism is the wrong attitude. Our goal ought to be

> "change from within" not "revolution".

huh, i don't see somebody leaving to work at a different (be it bigger
or smaller or whatever) place as anything inherently wrong. it rather
shocks me that anybody could consider it appropriate to tell another
person where they should/n't stay for their job.

i found the wording of the original post quite strange overall!
imhumbleo, revolution would be walking into the CEOs office and
pointing a gun at their head; leaving for something else that would
simply be competion is not revolution. it might be 'secessionism' of
some form, but i don't see it as mattering.

sincerely.

[Dave Hoover]

On Mon, Apr 13, 2009 at 1:06 PM, Robert Martin
<uncl...@objectmentor.com> wrote:
> I heard today from someone that the software craftsmanship movement has
> adopted a secessionist attitude.  Specifically they said that the folks
> involved have decided to move to boutique shops because they can't be
> craftsmen in corporate IT.  This harkens back to Martin Fowler's famous
> dipole: "Change your organization or change your organization."

I created a "boutique shop" within Obtiva's existing business of
consulting at corporate IT shops. We rotate people into our Software
Studio (aka "boutique shop") and out to larger corporate environments.
This allows us to bring up apprentices in a safe, friendly
environment and then give them the opportunity to experience corporate
environments. In this way, we get to change organizations and also
change organizations.

I don't view what we do as successionist. We are still actively
engaged in several corporate IT consulting gigs and have no plans to
pull out of that business.

Best,

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

[Corey Haines]

I've fielded this question quite a few times while talking to people. Here's my take on it.

Perhaps the impression that we are 'secessionist' comes from being open and honest about the differences in the cultures.

The world in corporate IT is a different place than the world in a boutique shop. I feel that it is much more likely to be able to pursue the craft in a community of support in a boutique shop. Corporate IT isn't focused on the qualities we try to live by, and they have the time and money to support the waste inherent in their systems. I often quote the saying 'the poor can't afford cheap' to people in relation to this. The flip to this is that the large corporate IT shops can afford to survive while wasting time and money on inefficient, inexperienced and just generally crappy software development practices. This is a huge generalization, but my experiences both personally and talking to others justifies it in my mind. Does it mean that we should abandon them? No, it doesn't. However, I am always happy when I talk to someone that has spent significant time struggling upstream in the corporate waters, and they tell me they are leaving to join a small shop. One thing that a lot of people have told me is that they were happy to meet me, because they weren't even aware of the existence of these small shops where they can really pursue their craft in a a supportive environment.

Personally, I'm more interested in showing people that there are other options. I left the corporate environment, and I don't intend to go back for anything other than to enlighten people about better practices. That's just me, though. There are a lot of people who are very interested and proficient at going in and really making a different in the environment, people like Cory Foy (who is awesome, even if he doesn't have an olde thyme e in his name). There are people who are well-suited for the large corporate IT environment, and there are people (like me) who are not. The sad part is when you have people trying to survive in the wrong environment.

I use that quote from Martin Fowler a lot with people that I take to. I think it is very important for people to realize that there are other options.

I don't have anything huge against corporate IT, but the message that I try to take to people is that you need to stop making excuses for your company. You don't owe them anything, just like they don't owe you anything. It is easy for people to be in a bad situation and justify it to themselves through inappropriate rationalization.



-Corey

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

[Francesco Rizzi]

Definitely agree with Uncle Bob's point below.

In the spirit of [quote]Our goal ought to be "change from within" not "revolution".  [/quote]
I propose that those in a "Corporate Environment" (vs "smaller boutique") might consider this motto:
"Be subversive, rather than secessionist"

I work in a small/medium size company that I cannot describe as a lean boutique, so I sympathize. For the time being, I'm still trying to change the organization, rather than change the organization I work for. The results are varied, of course, which can be frustrating but shouldn't keep a craftsman from a continued effort in bettering themselves and the organization.

HTH,
F.O.R.

On Mon, Apr 13, 2009 at 2:06 PM, Robert Martin <uncl...@objectmentor.com> wrote:

[Dave Hoover]

On Mon, Apr 13, 2009 at 1:06 PM, Robert Martin
<uncl...@objectmentor.com> wrote:
> Indeed, there is something to be said for doing it where its
> *hard* as opposed to where it's easy.  Which is the greater craftsman: the
> one who can hold his/her disciplines under adversity, or the one who faces
> no adversity?

At the risk of going off-topic, I'll point out that I have had similar
thoughts about working with a tough, legacy codebase. Which is the
greater craftsman: the one who can build a feature into a non-existent
codebase, or the one who can build a feature into an extremely chaotic
codebase? I'm reminded of the houses that are built into a
mountainside vs. houses that are built on the prairie. There, now
I've officially taken us off-topic. :)

[David Stanek]

On Mon, Apr 13, 2009 at 3:08 PM, Corey Haines <corey...@gmail.com> wrote:
>
> Perhaps the impression that we are 'secessionist' comes from being open and
> honest about the differences in the cultures.
>

To me the OP was about some of the elitist, or close to it, comments
about software craftsmanship. There have been numerous 'must be our
way' and 'your way can\'t work' posts on this list, in blogs and on
twitter. And if that is not what it was about I think it should have
been.

For me craftsmanship boils down to improving myself and the community around me.

--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek

[Mark Nijhof]

Dave,

I would say depends on how the new feature is implemented. In either
scenario this can be done good or poor. The Craftsman will do his best
to do it good. This will be easier in a happy environment :)

-Mark

[Keith Braithwaite]

On Apr 13, 8:08 pm, Corey Haines <coreyhai...@gmail.com> wrote:
> Corporate IT isn't focused on the
> qualities we try to live by, and they have the time and money to support the
> waste inherent in their systems. I often quote the saying 'the poor can't
> afford cheap' to people in relation to this. The flip to this is that the
> large corporate IT shops can afford to survive while wasting time and money
> on inefficient, inexperienced and just generally crappy software development
> practices.

There is a window of opportunity, right now (April 2009), for anyone
who wants to make changes in the way that corporate IT works, because
_right now_ is the time that they can least afford to waste time and

money on inefficient, inexperienced and just generally crappy software
development practices.

My colleagues in Switzerland who do Lean consultancy (I mean proper
lean Lean, in factories that make things with production lines) say:
"cut costs to increase quality". Only they say it in German, which is
much more impressive.

There's something in that, and this of all times is the time that
someone in the corporate hierarchy might just be persuaded to listen.

Keith

[Mark Nijhof]

Cutting cost in Software Development usually results in lesser quality
(for the wrong reasons but still).

[Raoul Duke]

> Cutting cost in Software Development usually results in lesser quality
> (for the wrong reasons but still).

there's a whole bunch of people who work on / have experience with
mapping Lean to software. i'm not one of them but... my understanding
is that "cost" is viewed appropriately as e.g. technical debt or
what-have-you, not so much just $ where they'd recommend "lay off
everybody!"

sincerely.

[Dave Hoover]

On Mon, Apr 13, 2009 at 3:59 PM, Keith Braithwaite
<ke...@keithbraithwaite.demon.co.uk> wrote:
>
> My colleagues in Switzerland who do Lean consultancy (I mean proper
> lean Lean, in factories that make things with production lines) say:
> "cut costs to increase quality". Only they say it in German, which is
> much more impressive.

I agree that now is a great opportunity to introduce change into
existing environments because people are feeling pain. One of the
ways that Software Craftsmanship proposes to cut cost is by using
small, tight-knit teams of generalists rather than larger teams of
specialists. We've found success with this approach at Obtiva with
our teams of generalists.

[Michael Hunger]

I completely agree with you. But citing Elements of Style seems to be dangerous as I've learned recently :)

50 Years of Stupid Grammar Advice -By GEOFFREY K. PULLUM
http://chronicle.com/free/v55/i32/32b01501.htm

Michael

[Michael Hunger]

> My goal, as a developer, is to write the absolute best code I can, at
> the time. William Strunk of the /Elements of Style/ states:
>
> "Vigurous writing is concise. A sentence should contain no
> unnecessary words, a paragraph no unnecessary sentences, for the same
> reason that a drawing should have no unnecessary lines and a machine
> no unnecessary parts. This requires not that the writer make all
> sentences short or avoid all detail and treat subjects only in
> outline, but that every word tell."

I'd like to cite another elements of style: That of Christopher Alexander where he lists 15 elements of Architectural
style. Interestingly many of them can be applied to code as well.
(http://www.weepingash.co.uk/tools/tool02.html)

My favorites:
14. Simplicity & Inner Calm
Use only essentials; avoid extraneous elements.
7. Local Symmetries
Organic, small-scale symmetry works better than precise, overall symmetry.
12. Echoes
Similarities should repeat throughout a design.

Michael

Here are all of them:
1. Levels of Scale
A balanced range of sizes is pleasing and beautiful.

2. Strong Centers
Good design offers areas of focus or weight.

3. Boundaries
Outlines focus attention on the center.

4. Alternating Repetition
Repeating elements creates a sense of order and harmony.

5. Positive Space
The background should reinforce rather than detract from the center.

6. Good Shape
Simple forms create an intense, powerful center.

7. Local Symmetries
Organic, small-scale symmetry works better than precise, overall symmetry.

8. Deep Interlock & Ambiguity
Looping, connected elements promote unity and grace.

9. Contrast
Unity is achieved with visible opposites.

10. Gradients
The proportional use of space and pattern creates harmony.

11. Roughness
Texture and imperfections convey uniqueness and life.

12. Echoes
Similarities should repeat throughout a design.

13. The Void
Empty spaces offer calm and contrast.

14. Simplicity & Inner Calm
Use only essentials; avoid extraneous elements.

15. Not-Separateness
Designs should be connected and complementary, not egocentric and isolated.

[Paul Pagel]

UB,

If you are working in a hostile environment to craftsmanship, I see how it can be tempting to leave and find work in an environment that rewards good code and personal relationships (i.e. some small boutique software shops fit that bill, rather than a larger organization focusing on developing as craftsmen).  Is it the professionalism of the individual to stick around and make the situation better for writing high quality code?  Or is the corporation responsible for retaining/empowering those that care about quality?

Paul

[Keith Braithwaite]

On Apr 13, 10:01 pm, Mark Nijhof <mark.nij...@gmail.com> wrote:
> Cutting cost in Software Development usually results in lesser quality
> (for the wrong reasons but still).

Cutting costs to spend less will typically do that, yes. But that's
not the recommendation. The part of Lean thinking that I don't see
making over into the software flavour very well is to do something
_radically_ different from what you are doing now, that increases
quality and reduces cost.

Keith

[Dave Rooney]

Paul Pagel wrote:
> If you are working in a hostile environment to craftsmanship...

Is this perhaps why some believe that there's an air of elitism in this
group? Corporate IT isn't "hostile", it's just dealing (incorrectly)
with the fact that IT itself is a support unit and not a fundamental
driver of the business. It may be an important support unit that can
have direct impacts on revenues, but it's a support unit nonetheless.

In a corporate environment, we need to demonstrate that the ROI of a
high-quality "craft" approach to building software is achieved
relatively quickly. We need to make it so clearly evident that it's a
better approach than "just get it done, and we'll clean it up later",
that the people at or near the top of the corporate food chain buy in.
They don't give a flying you-know-what about a "craftsmanship movement"
- they do, however, give one about better project throughput and lower
cost (as opposed to "price"). We have to make it real for *those*
people, not just for us.

--

Dave Rooney
Mayford Technologies
"Helping you become AGILE... to SURVIVE and THRIVE!"
http://www.mayford.ca
http://practicalagility.blogspot.com
Twitter: daverooneyca

[Paul Pagel]

I am sorry if I was poor in articulating my question, and apologize
for any unintentional cynicism towards corporate development. I did
not intend draw the correlation between corporate environment and
hostile to craftsmanship (I did use it as the example, so I get where
your coming from). I would like to suppose a hostile environment to
craftsmanship, be it boutique or corporate, and want to know if it is
the craftsman's responsibility to change the environment within or is
it better to jump ship to a company that values craftsmanship and you
will be much more productive and happy at. Can you change the
organization by leaving?

Paul

[Paul Pagel]

>
> In a corporate environment, we need to demonstrate that the ROI of a
> high-quality "craft" approach to building software is achieved
> relatively quickly.

I agree. How do you propose to do that?

> They don't give a flying you-know-what about a "craftsmanship
> movement"

Why do corporations go 'agile'? Do they care about these movements in
development to some extent?

>
> - they do, however, give one about better project throughput and lower
> cost (as opposed to "price"). We have to make it real for *those*
> people, not just for us.

This is the big questions to me. How do we convince an organization
that quality = cheaper? That the quality of code will have a direct
effect on the price of the project?

Paul

[Anne Epstein]

I don't think you can change an organization by leaving. If anything,
it may just confirm to the organization that you were not a good
fit-and they'd probably be right.... signing on to fight for change
in a resistant organization is a tough road that doesn't make a lot of
friends. On the other hand, you probably can't change it by staying
either: see Doc List's post on change:

http://www.stevenlist.com/blog/2009/04/13/you-cant-change-me/

He was talking about creating change in a person, but I think an
organization may be the same... we can't force an organization change,
a critical mass of the people within it have to decide for themselves
that change is worth doing. If you see that critical mass is open and
ready but need guidance, staying might be very useful-you could be the
chance to be the catalyst, which would be exciting! If not, that
tough road might not have anything at the end of it but exhaustion.

A

[Gilberto Delgado]

Although just packing up and going seems noble and
courageous it is probably not the reality for most people.
It may not be possible for one developer to change the
culture inside a Corporation but it is certainly possible
for them to plant a seed.

It is also possible to do the best work you can within the
constraints of the environment. It may even be beneficial
if you are able to show specific examples of how those
constraints impede efficiency.

Change in Corporations is hard and takes time so it may
not happen in the developers "lifetime" with the Company,
but maybe by getting the conversation going someone will
pick up the torch after they are gone.

[Dave Hoover]

On Tue, Apr 14, 2009 at 9:05 AM, Paul Pagel <paulw...@gmail.com> wrote:
>

>> - they do, however, give one about better project throughput and lower
>> cost (as opposed to "price").  We have to make it real for *those*
>> people, not just for us.
>
> This is the big questions to me.  How do we convince an organization
> that quality = cheaper?  That the quality of code will have a direct
> effect on the price of the project?

Similarly, how do we convince an organization that attracting and
growing 3-4 craftsmen and paying them $500k per year is both cheaper
and more productive than managing 16 specialists and paying them $1M
per year?

The way that I'm currently convincing organizations of this is by
creating small teams of craftsmen who deliver value consistently to
customers.

[LudovicoVan]

On 14 Apr, 14:08, Dave Rooney <daveroone...@gmail.com> wrote:

> In a corporate environment, we need to demonstrate that the ROI of a
> high-quality "craft" approach to building software is achieved
> relatively quickly.

With "craftsmanship" as an approach to production, we build at the
best possible level (high quality, low cost), around the optimal
balance between prototyping and crafting.

A mature such production unit certainly delivers a higher ROI, here
and now, and impressively higher. In general, it is a long-term
commitment, and a strategic decision. The ROI grows progressively, as
a consequence of the increasing knowledge and quality of the assets,
and the initial investment is minimal, except from the day-before-
yesterday perspective.

In fact, in my experience across small/medium realities, resistance is
mostly at management level, where a change in perspective, and partly
in the practices, is really needed. Neither the customer is (directly)
interested in these details, nor are the developers (unless, again,
for mismanagement). Indeed, they both tend to consider such changes
with entusiasm: better + cheaper!

-LV

[Curtis Cooley]

On Mon, Apr 13, 2009 at 2:30 PM, Michael Hunger
<mic...@passionate-developers.org> wrote:
>
> I completely agree with you. But citing Elements of Style seems to be dangerous as I've learned recently :)
>
> 50 Years of Stupid Grammar Advice -By GEOFFREY K. PULLUM
> http://chronicle.com/free/v55/i32/32b01501.htm
>

Wow, an Englishman complaining about how American's speak and write
English. How novel ;)
--
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.

[J. B. Rainsberger]

On Mon, Apr 13, 2009 at 15:06, Robert Martin <uncl...@objectmentor.com> wrote:

> My view is that a professional simply does the best job possible in the
> environment where they work.  If you are in corporate IT, you do the best
> job you can there.  If you are in a boutique, you do the best job you can do
> there.  Moving from one to the other does not necessarily make you
> a craftsman.  Indeed, there is something to be said for doing it where its
> *hard* as opposed to where it's easy.  Which is the greater craftsman: the
> one who can hold his/her disciplines under adversity, or the one who faces
> no adversity?

A fine question. Perhaps this group doesn't include a large number of
people willing to act as pioneers in this regard -- or perhaps they
have been suffering in relative silence and want a break to spread
their wings and fly.

> In any case, secessionism is the wrong attitude.  Our goal ought to be
> "change from within" not "revolution".

I don't think people here have "the wrong attitude". Why can't we do
both? Maybe we have been doing both.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice
Register for Agile 2009 at http://www.agileregistration.org

[J. B. Rainsberger]

On Mon, Apr 13, 2009 at 17:59, Keith Braithwaite
<ke...@keithbraithwaite.demon.co.uk> wrote:

> My colleagues in Switzerland who do Lean consultancy (I mean proper
> lean Lean, in factories that make things with production lines) say:
> "cut costs to increase quality". Only they say it in German, which is
> much more impressive.

But they say it in Swiss German, which makes it less impressive.
Austrian German would sound better.

[J. B. Rainsberger]

On Tue, Apr 14, 2009 at 11:50, Dave Hoover <dave....@gmail.com> wrote:

> Similarly, how do we convince an organization that attracting and
> growing 3-4 craftsmen and paying them $500k per year is both cheaper
> and more productive than managing 16 specialists and paying them $1M
> per year?

Forget convincing. Just do it and still charge them $16M. Pocket the profit.

> The way that I'm currently convincing organizations of this is by
> creating small teams of craftsmen who deliver value consistently to
> customers.

Aha. You already get it.

[James Martin]

On Tue, Apr 14, 2009 at 8:46 AM, Paul Pagel <paulw...@gmail.com> wrote:

UB,

If you are working in a hostile environment to craftsmanship, I see how it can be tempting to leave and find work in an environment that rewards good code and personal relationships (i.e. some small boutique software shops fit that bill, rather than a larger organization focusing on developing as craftsmen).  Is it the professionalism of the individual to stick around and make the situation better for writing high quality code?  Or is the corporation responsible for retaining/empowering those that care about quality?

I think it also depends on the level, or experience, of the craftsman. Personally, I'd consider myself a novice and currently feel extremely isolated in my environment. Without the opportunity to learn from a mentor during my most productive working hours during the day, I relying entirely on self-study during my own time and am sure that I would benefit from moving to a smaller/boutique shop.

Even more experienced journeymen must feel this if they find themselves isolated inside corporate IT, where they have neither mentors or allies in their quest for change.

So while it's likely that the "greater craftsman [is] one who can hold his/her disciplines under adversity", anyone other than a master craftsman in these circumstances would probably not be able to effect the right change without growing disillusioned or without sacrificing their own progression.


Thanks,
James.  

[LudovicoVan]

On 19 Apr, 09:44, James Martin <jimmymar...@gmail.com> wrote:

> So while it's likely that the "greater craftsman [is] one who can hold
> his/her disciplines under adversity", anyone other than a master craftsman
> in these circumstances would probably not be able to effect the right change
> without growing disillusioned or without sacrificing their own progression.

As they say: think global, act local. Corollary: start small...

IMO: The idea that there is more to learn in a little shop is not too
mistaken, but you can still work, though more "confined", even in a
corporate env. And if not even that is allowed, definitely change as
soon as you can, big or small that it is, young or experienced that
you are.

-LV