Slightly Off Topic: Lean Architecture for Agile Software Development

[Christopher Gardner]

Has anyone on this list read this book?

http://www.amazon.com/dp/0470684208/ref=rdr_ext_sb_ti_hist_3

[Steve Freeman]

I've skimmed it at a book stall. From what I remember, it's a bit of a hodge-podge, some good bits some less so. And, of course, he hates TDD.

S.

[philip schwarz]

Does the book discuss TDD?

[Steve Freeman]

My recollection is that he mentions it enough to claim that it's a bad idea.

Steve Freeman
http://www.m3p.co.uk/blog

Written on a phone, so please allow for typos and short content.

[Esko Luontola]

On Dec 8, 9:09 am, Steve Freeman <st...@m3p.co.uk> wrote:
> And, of course, he hates TDD.
>

BTW, would somebody happen to know _why_ he hates TDD so much?

[Simon Harris]

> BTW, would somebody happen to know _why_ he hates TDD so much?

For the same reasons many people like TDD, it's fashionable to do so?

[J. B. Rainsberger]

Near as I can tell, he believes that you can't TDD a decent architecture.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca :: http://blog.thecodewhisperer.com
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice :: Agile 2010: Learn. Practice. Explore.

[Simon Harris]

On 08/12/2010, at 7:57 PM, Simon Harris wrote:

>> BTW, would somebody happen to know _why_ he hates TDD so much?
>
> For the same reasons many people like TDD, it's fashionable to do so?

For the record, I'm *in* the fan club ;-)

[Steve Freeman]

A number of reasons, some of which should only be discussed over a beer;) I think some of it was coloured by early studies when, frankly, we were all struggling with the technique.

Steve Freeman
http://www.m3p.co.uk/blog

Written on a phone, so please allow for typos and short content.

[Raoul Duke]

On Wed, Dec 8, 2010 at 12:55 AM, Esko Luontola <esko.l...@gmail.com> wrote:
> BTW, would somebody happen to know _why_ he hates TDD so much?

here's my straw-man stereotyped summary of the viewpoint.

you can do either a functional decomposition of a system to build, or
you can do a domain model study and then implement
user-facing-features on top of that. bog-standard uneducated TDD can
lead you to do functional decomposition, which in theory is the old
broken static hard-to-change way to do architecture that was obsoleted
by e.g. oo-ish thinking.

sincerely.

[Steven Mak]

For the records from Jim :)

http://www.infoq.com/interviews/coplien-martin-tdd

[Esko Luontola]

On Dec 12, 8:06 pm, Steven Mak <steven...@gmail.com> wrote:
> For the records from Jim :)
>
> http://www.infoq.com/interviews/coplien-martin-tdd
>

Thanks for reminding about that discussion. Based on that video, to me
it seems that Jim doesn't like the de-emphasis that some people put on
architecture and up-front design when teaching TDD.

Also he says that "unit testing was a great idea in Fortran, when you
could build these layers of APIs and the units of organization of the
software were the same as the units of testing, but today the units of
organization of the software are objects and we're testing procedures
and there is a little bit of a mismatch" and "you can't refactor your
way out of this because the refactoring has to be across class
categories, across class hierarchies, and you no longer can have any
assurances about having the same functionality." So appears to have
the point of view that in TDD the unit tests have a direct relation
with the structure of the production classes.

I, on the other hand, try to avoid a direct relation between unit
tests and the code which passes them. Instead I organize my unit tests
around the behaviour of the system [1] (though many times also the
structure of the system is organized around the behaviour, due to
following the Single Responsibility Principle, but even then the
structural relation between the tests and production code is
inadvertent). So I don't agree with Jim's notion of there being a
mismatch. The kind of tests to write is orthogonal to the mechanics of
TDD - skill is needed to write good tests which do not suffer from
fragility when the system under test is refactored or rearchitected.

Jim says that "one of the things we see a lot, in a lot of projects,
is that projects go south on about their 3rd sprint and they crash and
burn because they cannot go any further, because they have cornered
themselves architecturally." I think that is a good thing. TDD is
exposing problems with the design by increasing the pain [2] of
working with a bad design, and ultimately revealing the skill
deficiency [3] of its developers. The right way to react to this
feedback would be to improve the design and the skills of the
developers. So I think TDD works well when the developers create a bad
design and TDD grinds the project to halt - thus preventing the
shipping of crap. :) With a waterfall method the problem would have
been detected much later, maybe after many years when the developers
start demanding a rewrite. [4]

[1] http://blog.orfjackal.net/2010/02/three-styles-of-naming-tests.html
[2] http://blog.orfjackal.net/2010/04/direct-and-indirect-effects-of-tdd.html
[3] http://www.vimeo.com/groups/7657/videos/3756344
[4] http://www.informit.com/articles/article.aspx?p=1235624&seqNum=3

[J. B. Rainsberger]

On Sun, Dec 12, 2010 at 20:55, Esko Luontola <esko.l...@gmail.com> wrote:

Jim says that "one of the things we see a lot, in a lot of projects,

is that projects go south on about their 3rd sprint and they crash and
burn because they cannot go any further, because they have cornered
themselves architecturally."

Wow. So teams that don't know much about design have a tough time designing incrementally. In other news: water, wet; sky, blue.

Of course, the best way to handle this situation is to do all the important thinking for them so they don't have to learn how to design well.

[Steve Freeman]

Having been ambushed by Jim at a conference talk, I don't have the warm feelings to him I ought to. A couple of points, I think we now understand TDD better than we did when he was looking into it although it's still a minority sport (just like real OO). Not everyone in the world is building multi-million line switching systems, or even apps with a user interface. Third, he's been so busy proving that it doesn't work (he's used much stronger language) that he and the people he's influenced have missed a seriously interesting phenomenon. 

S. 

[J. B. Rainsberger]

On Mon, Dec 13, 2010 at 04:37, Steve Freeman <st...@m3p.co.uk> wrote:

Having been ambushed by Jim at a conference talk, I don't have the warm feelings to him I ought to.

Based on my experience, you have quite a reasonable level of warmth in your feelings about him.

--