DHH 2014 keynote

[Christopher ánd Shalan Galtenberg]

(Stealing Jonah's post over to a new thread)

(Keynote link: http://www.justin.tv/confreaks/b/522089408 start at 11:36)


Interesting that "reasoning about a system" was one of DHH's keynote mantras. He's just still so attached to MVC-rails way, hasn't taken to DCI (tho promoted Concerns after conversations about it) -- you'd think the discussions of "objects as little computers" and the many roles a model plays would move the needle a bit more.

Also interesting from the keynote: the link to the humanities (as a writer, I found many points of agreement), and Information Systems vs Comp Sci (gets to the heart of modern developer mindsets). Lots of good fodder.


On Tuesday, April 22, 2014 6:46:34 PM UTC-7, jona...@gmail.com wrote:

    Cope,
    While on the subject of HackerNews flame bait, I wonder if you saw DHH's rails keynote speech, as your paper Why Most Unit Testing Is A Waste was quoted in it, in a way I thought might have mis-represented your intent.  The quote, I believe, was this:

        If you find your testers splitting up functions to support the testing process, you’re destroying your system architecture and code comprehension along with it. Test at a coarser level of granularity.

    DHH referenced it to support his argument that architectures in which the pieces can be broken apart and tested independently are often difficult to decipher: ie, testability comes at the expense of clarity.  I've found precisely the reverse to be true, and I wondered what you thought.  As I understood it, your paper took issue with with unit testing for completely different reasons, and this specific quote is warning against testing at the wrong level of detail (eg, making private methods public, or moving them into their own class, so they can be directly tested), but is still in complete harmony with the view that a good architecture consists of decoupled components which must be independently testable, regardless of whether they are in fact covered by unit tests. 
    I'd love to hear what you think.
    Jonah

On Wednesday, April 23, 2014 3:37:57 AM UTC-7, Cope wrote:

Hej, Jonah,

I wasn't there and am currently on a train with a sloooow internet connection so have difficulty getting to the original, so it's hard for me to know what DHH said in context. From what you describe I have no problem with the gist given what you summarize below. If you take a big chunk of code that's comprehensible in its own right, and split it into small bits, each of the small bits becomes increasinglly undercontextualized and difficult to understand. It's like taking the sentence, "Come on baby light my fire" and splitting out the word "fire" and asking you what it means (without understanding the full context in which it is invoked).

Decoupling between components relates to testing only as a second-order effect. In some domains, complexity dictates that there be essential, complex coupling between domains or components. To abstract away that complexity is to make evolution difficult. But thinking about testing this way does give me another reason to be skeptical about unit testing and to favour system testing more (and the DCI approach along with it): with unit testing you end testing a caricature of the unit instead of viewing it in its full glory. It's kind of like Weinberg's Law of Decomposition.

As I think I talked about in the article, at my last client management rewarded people on the basis of code coverage for individual units. Large functions (tens of lines) with interesting branching were difficult to cover completely (it's hard to get complete branch coverage if you have more than a handful of branches) so they broke the big functions down into small ones of just a half-dozen lines or so, and often smaller, so that test coverage was easier for each one. That ensured that people got their bonuses. Three cheers for quality. It destroyed their architecture.

I think this mentality also predominates class-oriented systems with heavy IDEs. I've heard it quoted that the average length of a Smalltalk method is about 3 "statements". Trygve once balked at this suggestion and then measured it in his own code and found that the figure wasn't far off the mark... (Smalltalk of course is the product of small, incremental research experiments, so the system grew by subclassed patches with small methods to try things out. It's a prototype that someone forgot to throw away. Trygve tells me that Alan wanted to burn the Smalltalk image disk and start over but the community balked. Alan left.)

Anyhow, I'd welcome any dialog from DHH if there's a feeling about any unclarity about our positions on this issue. I'll try to look up the original once my train lands.

[Raoul Duke]

> a handful of branches) so they broke the big functions down into small ones
> of just a half-dozen lines or so, and often smaller, so that test coverage
> was easier for each one. That ensured that people got their bonuses. Three
> cheers for quality. It destroyed their architecture.

¿

i don't see there being a direct necessary causal link here. i believe
there can be smaller things and yet still have a good architecture. i
would appreciate hearing more thoughts about why sometimes it appears
braking big functions down is bad for architecture.

i'd guess of the top of my head one thing might be that if breaking
things down into smaller parts destroys the architecture that the
architecture was probably bad to begin with. one big fn moving to
smaller ones shouldn't materially affect the architecture at all.
design yes, architecture no.

thank you.

[James O. Coplien]

Den 23/04/2014 kl. 22.47 skrev Raoul Duke <rao...@gmail.com>:

> i don't see there being a direct necessary causal link here.

But that's how it happened — this isn't theory, but a real occurrence.

[James O. Coplien]

Den 23/04/2014 kl. 22.47 skrev Raoul Duke <rao...@gmail.com>:

> i believe
> there can be smaller things and yet still have a good architecture.

Architects (like Alexander) talk about two things with regard to size. One is to build at human scale: things should be humanly comprehensible. The other is levels of scale: no thing should be broken down more than a factor of two or three from its supertending structure. If you break down a meaningful 100-line algorithm into 3-line fragments, you violate the human mind's ability to reason about enough things simultaneously to be able to make sense of them. Short term memory can keep about five things — seven at the most, more or less — in short-term memory to be able to reason about them together. Breaking down a gestalt into more than seven things doesn't work. That translates into lines of code, and supports my argument.

Of course, experience and common sense do, too....

So I guess I disagree.

[Raoul Duke]

> Architects (like Alexander) talk about two things with regard to size. One is to build at human scale: things should be humanly comprehensible. The other is levels of scale: no thing should be broken down more than a factor of two or three from its supertending structure. If you break down a meaningful 100-line algorithm into 3-line fragments, you violate the human mind's ability to reason about enough things simultaneously to be able to make sense of them. Short term memory can keep about five things -- seven at the most, more or less -- in short-term memory to be able to reason about them together. Breaking down a gestalt into more than seven things doesn't work. That translates into lines of code, and supports my argument.

> Of course, experience and common sense do, too....
> So I guess I disagree.

i'd agree that we want things to be "as simple as possible but no
simpler" as in don't make it into something that has gone into
"simplistic" territory. i do not n e e d e a c h l e t t e r o f
m y p r o g r a m to be split out into its own method and then
recombined with some functional map() applied to the array of
individual letters. so yes there is a level at which the recursive
break down is jumping the shark.

but i don't believe even 10% of all software would fall into that
trap. 90% of all software is such bloated crap that there's a zillion
person-hours of breaking things down that can happen before it gets to
the breaking point.




i think there are times when there are seams along which things can be
nicely chopped up in a human-scale kind of way. hooray for such
situations. there are times when that is not possible or at least not
as easily possible. sure one should strive for that all the time, by
looking for better abstractions etc. but it seems simplistic to me to
claim human scale is always possible. if only there were a
four-quadrant diagram to explain what i have in mind... oh wait...
maybe vaguely something along the lines of
http://en.wikipedia.org/wiki/Cynefin, sorta.

furthermore, what is human scale when it comes to programming is not
just the # of lines of code.

from what (little) i've heard about large building architecture,
design, and implementation, actually there are lots of things in
constructing a real building that torpedo the nice dreams of the
architect. (i am a big fan of alexander, fwiw). stanford was only just
recently using fancy-pants CAD/CAM and had a lot less stupid crap to
fix in their new building. before, they'd be doing the work and the
contractor would be like "oh wait this pipe can't actually go here as
the blueprints would have you believe because duh there's a freaking
{wall,electrical system,other piping} already there and so i will just
re-route around it as best i can because to rip things out and do it
right would cost a zillion more dollars because this comes up all the
time" so you end up with hacked-up looking things *all the time*.
sometimes BDUF or simulating or using TLA et. al. actually is a good
idea $-wise. of course there are times when that's not so true.
context is king.

when somebody is programming in
something-other-than-{haskell,*ml,other-Real-languages} then there's
so much ancillary crap accidental complexity that 100 lines in a
method is pure evil. breaking it down is not actually making it into
things that are so small they are meaningless, it is rather actually
helping put up firewalls so that people can actually now focus on the
7+/-2 things in that single method and not all the stupid other junk
that (inevitably, unfortunately) they'll also have to consider.

furthermore, hasn't anybody ever heard of fractals. or seen powers of
ten. or considered that abstraction often is simply
things-within-things. we are breaking things down all the freaking
time. we want to break things down. we need to break things down. yes
breaking down to assembly or microcode is too far. but a few lines of
haskell is a lot better than a zillion. a few lines of C is a billion
times better than a zillion.

long methods are pretty much pure evil in my experience. in any
programming language. funny how the languages which have the worst
bloaty accidental complexity also tend to lack the compositional
abstractioning nice little powerful things that make it easy to factor
things out nicely, as simple as "let ... in ..." or "def ... where
..." so they sorta are just an evil double whammy.

:-)

[jona...@gmail.com]

Cope,

I think about it exactly like this, right down to the connection with short term memory.  I still don't see a problem with little pieces down at the bottom, as long as each level of the hierarchy doesn't get exploded too far.

As an anology:

A brick house with 5 rooms.

Each room with 4 (or so) walls.

Each wall is divided into "panels" of brick (I admit the analogy is slightly strained here, but the idea should be clear).  

Each panel is made up of individual bricks.

At each stage of the zoom process, the total number of elements is small enough to be held by the mind.  And yet the house itself is made up of little bricks.  

[rune funch]

Den 24/04/2014 kl. 11.08 skrev "jona...@gmail.com" <jona...@gmail.com>:

Cope,

I think about it exactly like this, right down to the connection with short term memory.  I still don't see a problem with little pieces down at the bottom, as long as each level of the hierarchy doesn't get exploded too far.

As an anology:

A brick house with 5 rooms.

Each room with 4 (or so) walls.

Each wall is divided into "panels" of brick (I admit the analogy is slightly strained here, but the idea should be clear).  

Each panel is made up of individual bricks.

At each stage of the zoom process, the total number of elements is small enough to be held by the mind.  And yet the house itself is made up of little bricks.  

So you understand what the construction is if you see the whole but can you understand the function of the individual pieces when you can't see the hole? Eg by looking at a panel do you know whether it's safe to remove it or that the house would collapse because it's part of the support structure?

On Wednesday, April 23, 2014 3:54:03 PM UTC-5, Cope wrote:

Den 23/04/2014 kl. 22.47 skrev Raoul Duke <rao...@gmail.com>:

> i believe
> there can be smaller things and yet still have a good architecture.


Architects (like Alexander) talk about two things with regard to size. One is to build at human scale: things should be humanly comprehensible. The other is levels of scale: no thing should be broken down more than a factor of two or three from its supertending structure. If you break down a meaningful 100-line algorithm into 3-line fragments, you violate the human mind's ability to reason about enough things simultaneously to be able to make sense of them. Short term memory can keep about five things — seven at the most, more or less — in short-term memory to be able to reason about them together. Breaking down a gestalt into more than seven things doesn't work. That translates into lines of code, and supports my argument.

Of course, experience and common sense do, too....

So I guess I disagree.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[jona...@gmail.com]

Well the little bricks are essentially implementation details of the panel in this analogy, so the panel is responsible for ensuring its own integrity should it decide to replace one or more of its bricks.  The wall, in turn, relies only on the promise that the panel has X load bearing capacity, Y shear stress capacity, and so on.

[rune funch]

That was not the question :)

Mvh

Rune

--

[jona...@gmail.com]

Fair enough but the answer is the same, mine was just one level further down the hierarchy :)

You asked: By looking at the panel, how do you know if it's safe to remove it?  The "Wall" is responsible for its panels.  The "Room" relies on the promise of each Wall, that is has X load bearing strength, and so on.  It doesn't care about how each wall achieves that.   The "Wall" knows how many panels it needs, and of what kind, to live up to that promise.  So you cannot know by looking at a panel if it's safe to remove, but you can know by looking at its containing wall.  

On Thursday, April 24, 2014 5:54:17 AM UTC-5, Rune wrote:

That was not the question :)

Mvh

Rune

Den 24/04/2014 kl. 11.34 skrev "jona...@gmail.com" <jona...@gmail.com>:

Well the little bricks are essentially implementation details of the panel in this analogy, so the panel is responsible for ensuring its own integrity should it decide to replace one or more of its bricks.  The wall, in turn, relies only on the promise that the panel has X load bearing capacity, Y shear stress capacity, and so on.

On Thursday, April 24, 2014 4:24:07 AM UTC-5, Rune wrote:

So you understand what the construction is if you see the whole but can you understand the function of the individual pieces when you can't see the hole? Eg by looking at a panel do you know whether it's safe to remove it or that the house would collapse because it's part of the support structure?

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[Jim Gay]

On Apr 24, 2014, at 9:17, jona...@gmail.com wrote:

Fair enough but the answer is the same, mine was just one level further down the hierarchy :)

You asked: By looking at the panel, how do you know if it's safe to remove it?  The "Wall" is responsible for its panels.  The "Room" relies on the promise of each Wall, that is has X load bearing strength, and so on.  It doesn't care about how each wall achieves that.   The "Wall" knows how many panels it needs, and of what kind, to live up to that promise.  So you cannot know by looking at a panel if it's safe to remove, but you can know by looking at its containing wall.  

This is not true in the slightest. 

You'll need to understand the entire structure to know if a wall is safe to remove. They are all interconnected parts. 

On Thursday, April 24, 2014 5:54:17 AM UTC-5, Rune wrote:

That was not the question :)

Mvh

Rune

Den 24/04/2014 kl. 11.34 skrev "jona...@gmail.com" <jona...@gmail.com>:

Well the little bricks are essentially implementation details of the panel in this analogy, so the panel is responsible for ensuring its own integrity should it decide to replace one or more of its bricks.  The wall, in turn, relies only on the promise that the panel has X load bearing capacity, Y shear stress capacity, and so on.

On Thursday, April 24, 2014 4:24:07 AM UTC-5, Rune wrote:

So you understand what the construction is if you see the whole but can you understand the function of the individual pieces when you can't see the hole? Eg by looking at a panel do you know whether it's safe to remove it or that the house would collapse because it's part of the support structure?

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--

Write intention revealing code #=> http://www.clean-ruby.com

Jim Gay

Saturn Flyer LLC

571 403 0338

[jona...@gmail.com]

Hey Jim,

I actually said that you could remove a panel by verifying with the wall that it was ok.  The wall has a certain contract that it can support X weight, etc.  

If we're now talking about removing walls, then in my analogy you would need to verify with the wall's containing room, and at that point yes you are almost at the highest structural level.  My point is that each level can makes promises to the levels above it, and depends on promises from those below -- nothing new there.  If you think such an approach cannot be made to work I'd love to hear an example of why not.

Btw I bought your book a couple months ago and have read ~70% of it so far and enjoyed it a lot.

Jonah

[rune funch]

Exactly, so if you miss the hole you might take uninformed decisions that brings the roof down

Den 24/04/2014 kl. 15.17 skrev "jona...@gmail.com" <jona...@gmail.com>:

Fair enough but the answer is the same, mine was just one level further down the hierarchy :)

You asked: By looking at the panel, how do you know if it's safe to remove it?  The "Wall" is responsible for its panels.  The "Room" relies on the promise of each Wall, that is has X load bearing strength, and so on.  It doesn't care about how each wall achieves that.   The "Wall" knows how many panels it needs, and of what kind, to live up to that promise.  So you cannot know by looking at a panel if it's safe to remove, but you can know by looking at its containing wall.  

On Thursday, April 24, 2014 5:54:17 AM UTC-5, Rune wrote:

That was not the question :)

Mvh

Rune

Den 24/04/2014 kl. 11.34 skrev "jona...@gmail.com" <jona...@gmail.com>:

Well the little bricks are essentially implementation details of the panel in this analogy, so the panel is responsible for ensuring its own integrity should it decide to replace one or more of its bricks.  The wall, in turn, relies only on the promise that the panel has X load bearing capacity, Y shear stress capacity, and so on.

On Thursday, April 24, 2014 4:24:07 AM UTC-5, Rune wrote:

So you understand what the construction is if you see the whole but can you understand the function of the individual pieces when you can't see the hole? Eg by looking at a panel do you know whether it's safe to remove it or that the house would collapse because it's part of the support structure?

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[Jim Gay]

On Thu, Apr 24, 2014 at 9:56 AM, <jona...@gmail.com> wrote:
> Hey Jim,
>
> I actually said that you could remove a panel by verifying with the wall
> that it was ok. The wall has a certain contract that it can support X
> weight, etc.

This discussion reminds me of non-Newtonian fluids which behave in
interesting ways depending upon the pressure applied. The individual
wall might be fine with a panel of bricks removed, but given it's
contextual application (under load from above or side) the removal of
the panel might be equivalent to the removal of the entire wall.
Or perhaps I don't understand what a "panel'" is.

>
> If we're now talking about removing walls, then in my analogy you would need
> to verify with the wall's containing room, and at that point yes you are
> almost at the highest structural level. My point is that each level can
> makes promises to the levels above it, and depends on promises from those
> below -- nothing new there. If you think such an approach cannot be made to
> work I'd love to hear an example of why not.

The answer is all in the context, or it's relationship to how it
interacts with other things.
I'd say there's not enough information here to know whether or not a
panel could be removed safely.

>
> Btw I bought your book a couple months ago and have read ~70% of it so far
> and enjoyed it a lot.

Thanks! Slow-going lately, but more coming soon.

>
> Jonah
>
>
> On Thursday, April 24, 2014 8:45:47 AM UTC-5, Jim Gay wrote:
>>
>>
>>
>> This is not true in the slightest.
>> You'll need to understand the entire structure to know if a wall is safe
>> to remove. They are all interconnected parts.
>>

> --
> You received this message because you are subscribed to the Google Groups
> "object-composition" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to object-composit...@googlegroups.com.
> To post to this group, send email to object-co...@googlegroups.com.
> Visit this group at http://groups.google.com/group/object-composition.
> For more options, visit https://groups.google.com/d/optout.



--
Write intention revealing code #=> http://www.clean-ruby.com

Jim Gay
Saturn Flyer LLC

571-403-0338

[rune funch]

> Den 24/04/2014 kl. 16.46 skrev Jim Gay <j...@saturnflyer.com>:
>
> The individual
> wall might be fine with a panel of bricks removed, but given it's
> contextual application (under load from above or side) the removal of
> the panel might be equivalent to the removal of the entire wall.

Or removing that panel is safe from the view of the wall and so was
removing another panel from another wall but removing both is not.
Doing safety critical systems or fault tolerant once you'll learn that
most sever bugs are of the "removing two panels" sort also simply know
as integration bugs and one reason why they are so frequent is because
no one saw the entire picture

[James O. Coplien]

Den 24/04/2014 kl. 11.08 skrev jona...@gmail.com:

At each stage of the zoom process, the total number of elements is small enough to be held by the mind.  And yet the house itself is made up of little bricks.  

No, sorry, it is made of quarks. Why are your houses made of things so large?

Bricks are not building elements at human scale. A house is made of rooms — it isn't made of bricks any more than a program comprises characters. The bricks are just a trick to define the rooms. And, in fact, I am watching a "brick house" go up in my neighborhood these days. The house itself is functionally complete in its wood framing; the bricks are only a facade for appearance. The same is true for the slate building just north of Østerport in Copenhagen. So I would guess it is with most houses these days.

Saying it's made of bricks is true but not as useful as saying it is made of room. If form is to communicate and support function, bricks are the wrong thing. You need concepts that work in concert at the level of human value.

[James O. Coplien]

Den 24/04/2014 kl. 11.34 skrev jona...@gmail.com:

Well the little bricks are essentially implementation details of the panel in this analogy, so the panel is responsible for ensuring its own integrity should it decide to replace one or more of its bricks. 

Panels do not volunteer to be responsible for anything and there are no consequences for the panel if we try to hold if accountable. The designer will look at the panel, its supporting structures, and the brick, in a process of change, to decide how to evolve it in a way that maintains structural integrity throughout the process. There is nothing intrinsic to the panel, its design, or its function that provides for that, unless by accidental happenstance.

Talking about small functions without reasoning about how they support programmer perception, supported by psychological models such as short-term memory or domain models, is akin to talking about bricks and panels in the way described in the above paragraph. I don't see how that fits into the kind of models we are discussing with DCI.

[James O. Coplien]

Den 24/04/2014 kl. 15.56 skrev jona...@gmail.com:

The wall has a certain contract that it can support X weight, etc. 

I suggest maybe a short course in structural analysis to "prop up" your analogies.

Two walls at right angles can stably support a much heavier load than a single wall can. And a triangular configuration is yet considerably stronger.

You would understand this only by understanding the relatively complex relations of force distribution through the walls by doing stress analysis of the whole. Understanding one wall gives you quite little information, I'm afraid.

[jona...@gmail.com]

Cope,

So clearly my hastily chosen metaphor was a poor one. But I can't tell if your critique is meant to apply only to my metaphor or to the actual point I was trying to make? If the latter, are you saying that some functions/methods should never be further subdivided, even if they 200 lines long, because they map to something in our mental model which we don't naturally subdivide conceptually? What if the methods we break them down with are private and used just to make the code more readable? I'm sort of guessing now what you meant.... Honestly I'm confused what the discussion is about anymore we've gotten so deep in metaphor land -- my fault for starting it :)

[James O. Coplien]

Den 23/04/2014 kl. 23.09 skrev Raoul Duke <rao...@gmail.com>:

but i don't believe even 10% of all software would fall into that
trap. 90% of all software is such bloated crap that there's a zillion
person-hours of breaking things down that can happen before it gets to
the breaking point.

No mass of rules about code structuring will save a fool, and I consider such folks outside my constituency.

The "right size" for a method varies widely and has supported perfectly literate code differently in many programming traditions. Back-in-the-day a good size was considered to be one screenful. For the days of the HP 2621 that was about 21 lines.

I don't know where the norms came from that pushed practice to miniaturized functions. It could have been Smalltalk (I don't know anyone who wrote functions that small before Smalltalk-80 came around) which, as described earlier, had small functions for what might be accidental reasons unworthy of emulation. I could well imagine that coverage testing and unit testing could well have abetted that trend but I think they became popular later.

Just as there are good novels that range from 100 pages to 1000 I think that methods can vary widely in their size, while being perfectly sized for comprehension. I have some 50-line functions that are perfectly comprehensible — at least to me and the other people who've had the occasion to read the code.

Occam's Razor is a timeless rule-of-thumb for managing complexity, and it's obvious to me that small functions destroy the contextualization necessary for systems understanding. Rune has argued that point effectively from one perspective. I can support the same perspective with a much different arguments, which is that small functions don't have enough context to really be understood in isolation. Consider an object like an iterator that has a begin method, a next method, and a more method. How can you understand any of those in isolation? How can you understand them outside the context of their idiomatic use in a given programming language? Language is about much more than things you can look up in a dictionary. Individual tiny procedures are like words or sentence fragments in a given language. I want paragraphs, or perhaps even chapters.

I think the literary analogies are much more accurate and powerful than anything relating to panels or bricks. Software isn't built of blocks: it is, or should be, akin to literature. And we understand literature in terms of the emergent properties of the synergy of the parts. To ignore this synergy isn't to be a programmer but only a technician. A great builder isn't conscious of the individual bricks she uses but assembles them to carve out the space they enclose. So it is with functions. To focus on understanding methods is to entirely miss the point: it no more helps you write a good program than understanding a tree supports you in the design of a great timber house.

[Trygve Reenskaug]

On 2014.04.25 20:26, James O. Coplien wrote:
> I don't know where the norms came from that pushed practice to
> miniaturized functions. It could have been Smalltalk (I don't know
> anyone who wrote functions that small before Smalltalk-80 came around)
> which, as described earlier, had small functions for what might be
> accidental reasons unworthy of emulation. I could well imagine that
> coverage testing and unit testing could well have abetted that trend
> but I think they became popular later.

A piece of history:
I believe the culprit is Larry Tesler who at the time worked in the
Smalltalk group at PARC. Smalltalk code used to be written in fair sized
files. Larry's slogan was: 'don't mode me in'. He invented the Smalltalk
class browser to reduce the number of modes. In this browser, a
hierarchy of lists let the programmer zoom in on any piece of code in
the system. The code text shows up in a pane in this tool. A side effect
of the browser was that people tended to write methods that fitted in
the browser's small text pane. This led to a fragmentation of the
programs that hadn't been there before.

IMO, this fragmentation went too far. It became hard to see the wood for
the trees (or the house for the bricks). DCI helps alleviate this
fragmentation.

[jona...@gmail.com]

Cope,

I've always loved the literature metaphor for code.  I'm still finding the conversation a little too abstract to be practically useful (for me personally).

I wonder if you could provide a small sample project (or selected source files of one) that you believe demonstrates long, but still easily comprehensible, methods that would be damaged by further subdivision.  I would ask for an example of a single method to make it easier, but I think you would object to that based on your point that understanding methods outside of their contexts is like trying to understand words outside of the sentences they're used in.

The reason I ask is that I've never personally run into an example of a 50+ line method that couldn't have been improved (imo, ofc).  This may reflect stylistic preference on my part, but I'd like to fully understand your view.  To run with the literature metaphor, there are surely good reasons to use very long sentences in fiction (Faulkner comes to mind), but in expository prose writing (and of course there are exceptions) they are with high probability a symptom of an opaque style and insufficient editing.  Thus you find ubiquitous rules-of-thumb such as "Write short, clear sentences" in many style guides, especially those for news outlets.  And for expository writing I think it's generally good advice.  I don't see any reason to think such rules shouldn't find counterparts is style guides for writing code, and writing code is much closer to expository writing than to fiction.  But again we're back in the land of metaphor, and analogies make no promises to uphold themselves in every detail.... which bring me back to that request for a concrete example :)

[James O. Coplien]

Den 25/04/2014 kl. 21.21 skrev Trygve Reenskaug <try...@ifi.uio.no>:

> DCI helps alleviate this fragmentation.

+1

[James O. Coplien]

Den 25/04/2014 kl. 21.19 skrev jona...@gmail.com:

which bring me back to that request for a concrete example :)

Here you go. Knock yourself out.

[Unmesh Joshi]

I think TDD is the term that is abused by consultants and the wisdom of patterns got lost in that.
Its proven that driving development with 'scenarios' helps. Scenarios define boundary to the problem and also help us decide where to start. Use Cases were all about this, so is BDD and TDD.  Thats 'Scenarios define problem"

There is a pattern called 'Programming Episodes'.

The pattern talks about 'Develop a program in discrete episodes. Select appropriate deliverables for an episode and commit sufficient mind share to deliver them' 

 because 'The depth, quality and value of programming decisions will be limited by the programmers ability to concentrate'

Scenarios help having these small, discrete programming episodes.

The other fundamental truth about software development is that design and coding are not isolated activities. We need to write code to get insights into design. To get to coding, we need to understand scenarios. The coding activity itself needs to be done in discrete episodes.

All this is always true, and can not be dead :-). When good developers talk about TDD, I have seen that they really mean above three things. It helps thinking about program in terms of use cases. It helps getting started with coding. It helps having discrete episodes. 

I have found Jim's Organizational patterns book immensely useful to get beyond the buzzwords and understand things beyond basics. 

On Thu, Apr 24, 2014 at 2:24 AM, James O. Coplien <jcop...@gmail.com> wrote:

Den 23/04/2014 kl. 22.47 skrev Raoul Duke <rao...@gmail.com>:

> i believe
> there can be smaller things and yet still have a good architecture.

Architects (like Alexander) talk about two things with regard to size. One is to build at human scale: things should be humanly comprehensible. The other is levels of scale: no thing should be broken down more than a factor of two or three from its supertending structure. If you break down a meaningful 100-line algorithm into 3-line fragments, you violate the human mind's ability to reason about enough things simultaneously to be able to make sense of them. Short term memory can keep about five things -- seven at the most, more or less -- in short-term memory to be able to reason about them together. Breaking down a gestalt into more than seven things doesn't work. That translates into lines of code, and supports my argument.

Of course, experience and common sense do, too....

So I guess I disagree.

[James O. Coplien]

Hi, Unmesh! I don't think I've seen you post here before — welcome!

The scope of your mail is curious because it starts with the testing discussion that's going on and which is certainly related to the issue of code comprehensibility that we hold dear in DCI, and ends with the Org Pats. Curiously, several of the reviews of the Lean Architecture book take note of the frequent invocation of the Org Pats.

I think there's some interesting work to be done to tie together organisational concerns with DCI. It wouldn't be the first time something like this has been done — Trygve's pattern language for MVC has a heavy organisational patterns component.

[Trygve Reenskaug]

grammar.y c confirms my experience: Long methods tend to list a number of trivial, but related details. The structure was always simple.

 Contrast the methods for displaying a gantt (bar) chart in prokon-3. Quite complicated algorithm that was simplified by splitting it into 4 role sub-methods, most less than 15 lines long:

1. refresh the "main method"
2. addLines "grid, "very simple""
3. addBottomAnnotation "very simple"
4. addLeftAnnotation "very simple"
5. addActivitySymbols "32 lines. Displays the bars for early, late, and planned execution times.Not trivial. "

---

--

Trygve Reenskaug      mailto: try...@ifi.uio.no
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27

[James O. Coplien]

Den 26/04/2014 kl. 11.06 skrev Trygve Reenskaug <try...@ifi.uio.no>:

grammar.y c confirms my experience: Long methods tend to list a number of trivial, but related details. The structure was always simple.

Show me how you could do it better with small methods, in a way that I could still understand the grammar as a whole by looking at whatever artefact you encase it in.

[Trygve Reenskaug]

Your grammar.y  example confirms my experience: Good, long methods tended to list a number of trivial, but related details and were not suitable for further fragmentation. The structure was always simple, so they were easy to understand. They did one thing, did it well, and should/could not be subdivided in a meaningful way.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Unmesh Joshi]

I think more than size of a method, what matters is 'names' used at right level at abstraction. At any point, if a reader needs to decode statements in a method to understand its meanings it bad. Same is true if there are unnecessary names introduced by smaller methods. That's the reason we have 'inline method' re-factoring, which is very commonly used.

--

[Philippe Vaucher]

Where is the 50 lines long method in here? The longest is `endedge` and it's around 30 lines.

Philippe

[James O. Coplien]

Den 26/04/2014 kl. 16.52 skrev Philippe Vaucher <philippe...@gmail.com>:

Where is the 50 lines long method in here? The longest is `endedge` and it's around 30 lines.

It's called yyparse and comprises most of the grammar productions in the entire file.

[James O. Coplien]

Den 26/04/2014 kl. 11.17 skrev Trygve Reenskaug <try...@ifi.uio.no>:

Your grammar.y  example confirms my experience: Good, long methods tended to list a number of trivial, but related details and were not suitable for further fragmentation. The structure was always simple, so they were easy to understand. They did one thing, did it well, and should/could not be subdivided in a meaningful way.

I think the structure is not simple. A key part of the structure of a grammar is the presence of shift/reduce and reduce/reduce conflicts. There is explicit recursion; in fact, in general you can view a yacc file as a collection of interwoven recursive calls. Do you claim to be able to see that in the source structure?

I don't think we need to make arguments about the complexity of the individual fragments or about simplicity. I think the only thing that matters here is that it's a whole that cannot and should not be decomposed. It has nothing to do with the structure being simple. I think it's quite a stretch to say that the structure is easy to understand. I think I could make my point by sending you the yacc file for a C++ compiler: that's probably hundreds, or conceivably thousands, of lines long.

Here is one I did for an industry standard hardware test specification language. I created it form a formal IEEE spec. It's about 1300 lines long. I suppose you could break out the token declarations and a bit of boilerplate, but the rest is monolithic. First, I dare you to tell me that it's simple and that you understand it. Second, I dare you to break it down into pieces which individually can be understood. (And, yes, this is one function, and its name is yyparse.)

The group denied the possibility of large functions. I think I came up with a smoking gun. Please do not try to be dismissive by trivializing the example. The original example I gave is every bit as rich in semantics as the equivalent Smalltalk code would be and, I would guess, even more so. And if you didn't believe that one, you'll certainly believe the CAD example.

I think I can always trump any objections you have with another example, but I'm not here to have a macho contest.

Complex things are complex. It takes a large mind to understand it. If you have simple things, by all means break them down according to the principles of psychological chunking. Some things are not easily chunkable. That's life. Please get over it.

 

[Trygve Reenskaug]

OK OK OK. I just glanced at the grammar.y code and its structure looked familiar. I stand corrected.

[James O. Coplien]

Den 27/04/2014 kl. 10.24 skrev Trygve Reenskaug <try...@ifi.uio.no>:

OK OK OK. I just glanced at the grammar.y code and its structure looked familiar. I stand corrected.

:-)

Happy Sunday.

BTW, the testing article has created a tremendous buzz on Twitter and a lot of it (no surprise) is turning in a DCI direction. Here's some of the bird fodder:

[Risto Välimäki]

> Bricks are not building elements at human scale.

Actually, in construction a "module" system is used. 1M = 10cm. Typically those modules are 30 cm long and 20 cm tall (3M x 2M respectively). Nowadays probably more often 30 x 30 cm (3M x 3M), that was what I used when designed and built my house from large styrofoam bricks (12Mx3M filled with concrete for outside facing walls and 6Mx3M bricks for indoor walls). That's a very reasonable design element and building element as well. Opening for doors are typically 21M high and 9M in width, so that's exactly 7 x 3M in height and 3 x 3M in width.

Bricks, lamps, cabinets, windows, doors. All these are typically module sized. For example newer "t5" standard lamps have lengths so that they fit n x 30cm module systems with casing. Older "t8" standard fluorescent tubes were troublesome for design, because tubes itself were module sized, but when casing is added, the whole lamp doesn't fit the module system anymore.

It's very easy to design and to build using 3Mx3M size modules, and I'd say that's a good scale for humans, too.

Traditional bricks would be too heavy with 3M x 3M, so they are often 1M x 3M or 2M x 3M (including mortar), when module sized. Of course there are also bricks that doesn't follow module system at all.

-Risto

--

[jona...@gmail.com]

Hey Cope,

Thanks very much for the examples.  

I think I need a little help with them, though, as I'm not familiar with yacc.  Literally just looking at how the text is laid out, and not understanding it, I have a couple questions.  My first relates to what we're considering a "method" or a "function" -- while I'm sure "stil.y" is technically a single method or function within yacc (since you wouldn't have produced it as an example otherwise), it appears to have many distinct, named conceptual parts, which to my mind is the key thing about methods or functions as they relate to this discussion.

Here's what I notice, again just by the textual layout:

1. Lines 1-311 are either comments or token definitions, one per line.  The one per line token definitions, in my mind, are a single conceptual unit, and might just as easily be considered a one line "method" as 311 lines.

2. The remainder of the file has a form like:

<some identifier>:  1-10 lines presumably defining that identifier somehow.

That is to say, this *appears* to be a file that conforms almost perfectly to the clean code "10 line method" philosophy.  It's a bunch of small, named chunks, each easily digestible.  

So I guess my question is: Is this impression wrong?  In what way is it wrong?  How am I being misled by the visual layout of the file?  Or maybe I'm not wrong, and our apparent disagreement was a matter of misunderstanding?

Thanks for any clarification.

[rune funch]

I'll jump in and answer some of your questions from my point of view

You are correct in the sense that they are conceptually different parts as are the cases of a switch case statement.

but you are incorrect in assuming they are not interrelated which is why I like this example. The examples are the grammar for a language if you take away on of the productions (that is one of the distinct parts) you have only part of the grammar and will not be able to understand the grammar without finding the missing pieces. Any production might loop back to any other production for it's definition so all the parts are on the same level of abstraction.

BNF (or eBNF) which is often used for grammars is a simple format with essentially two constructs the left hand side is an identifier and the right hand side is the definition a definition of integer addition might look like this

expression : INT

                   | addition

addition : expression OP_ADD expression

an expression can either be an int (terminal hence the upper case) or an addition. An addition in turn is made of three parts a LHS an operator and the RHS. both left hand and right hand side is an expression (an integer or an addition)and OP_ADD is a terminal that would be defined in the lexer as + (usually at least.

even with this simple grammar you would have an incomplete definition if you remove one part: I.e.

expression : INT | addition doesn't really tell you anything it's an incomplete definition that let's you know that and expression is either an integer or something else.

but the grammar is only one side of the story because the parser is usually tightly coupled to the translation from source code to an abstract syntax tree. Knowing how the productions are translated into the AST is vital to be able to work with the AST e.g. when doing source code transformation like what Marvin does.

If you remove one or more productions you no longer have a complete grammar if you loose part of the translation you have no one place to see the relation between source code and AST both very vital aspects when working with compilers and source code transformation. To be honest I was doubtful of Cope being able to come up with any solid example. I've advocated short methods myself, I actually did it on the project where I was fortunate enough to work with Cope for a while but I've learn that somethings aren't meant to be broken. Breaking these things up will make it harder to grasp the idea or might even mislead you. Take this silly example

let  Dostuff  = 

    generator1() + generator2()

That's a function definition in F# that calls two other functions (with no parameters) as arguments. The function calls both and invokes the `+` operator and returns the result. If it's the result of splitting the below function did it really add value?

let DoStuff  =

    1 + 2 

Yes you could argue that it's because the function was so simple that it shouldn't have been split. I'd argue that it's not because it's simple that it should be broken up but because it's the simplest way to write it. and the a short reminder this is not about specific examples but whether there are such functions that breaking them produce a more complex/harder to read result.

-Rune

p.s. jonah if you have a copy of clean code at your disposal then for kicks read the foreword :)

--

[Raoul Duke]

> let DoStuff =
> 1 + 2

yessir. context is king it is all subjective there's an inflection
point to be found a judgment call to be made etc. but for the most
part the majority of code i've ever seen in my working life is nowhere
near this, it is a zillion miles off into the left field of "i know
i'll just add my 10 lines of code for my feature/bug-fix into this
function that is already 100 lines long!" so while everything people
here say about NOT breaking things down makes a lot of sense in the
right place, i'm rarely in such a wonderful situation :-)

so you all are all in the right that sometimes one shouldn't break it
down. i just pray people don't take that the wrong way :-)

[James O. Coplien]

Den 28/04/2014 kl. 21.40 skrev Raoul Duke <rao...@gmail.com>:

> so you all are all in the right that sometimes one shouldn't break it
> down. i just pray people don't take that the wrong way :-)

I fear that you are trying to codify common sense.

Good luck.

[Raoul Duke]

>> so you all are all in the right that sometimes one shouldn't break it
>> down. i just pray people don't take that the wrong way :-)
> I fear that you are trying to codify common sense.
> Good luck.

what else are windmills for?

[James O. Coplien]

Den 25/04/2014 kl. 20.02 skrev jona...@gmail.com:

If the latter, are you saying that some functions/methods  should never be further subdivided, even if they 200 lines long, because they map to something in our mental model which we don't naturally subdivide conceptually?  

Yes. There is intrinsic complexity in some things that defies reduction, at least as it could benefit understanding.

What if the methods we break them down with are private and used just to make the code more readable?

I'm sure you could pronounce it faster... And I'm sure that it takes less time to read individual sentences than to read all of Moby Dick. But readability isn't the entire story, and comprehension is a big part of that. Appreciation comes in the whole. You don't appreciate the beauty of the Mona Lisa by studying only her nose: you take in the whole. It is more than the sum of its parts, just as understanding must be more than the sum of its parts.

There are some strange loops going in the other direction, and this is where I've picked up a new tool in the past weeks: Weinberg's law of decomposition. Each part is much more than a decomposition of the whole. Because it is so much more, it is harder to understand as an entity than it is to understand when contextualized by its surroundings. So the phrase, "Frankly, dear, I don't give a damn" has some meaning in its own right but 100 times as much meaning when read in the context of "Gone With The Wind."

Poetry is about about compression: about using cultural context, and the context of the rest of the work, to amplify meaning. Great software is group poetry writing. If you're not doing that, you're just a machine automating the generation of some object code in an assembly language called Java.

I'm sort of guessing now what you meant.... Honestly I'm confused what the discussion is about anymore we've gotten so deep in metaphor land -- my fault for starting it :)

It started with a question about sizing methods. DCI doesn't care. But I think it's worthwhile because people may confuse DCI with breaking down contexts into role methods for the sake of individual comprehension, since we say so much about comprehension. I view the comprehensibility to have a little bit to do with size but much more to do with the match to the mental model. That's where common sense comes in and where we should avoid legislating method sizes. I don't want people to get the impression that DCI is about small methods. I think Smalltalk can have that problem laid at its door for a variety of strange historic reasons and I certainly don't want to walk in its footsteps in that regard.

[Raoul Duke]

> Appreciation comes in the whole. You don't appreciate the beauty of the Mona
> Lisa by studying only her nose: you take in the whole. It is more than the
> sum of its parts, just as understanding must be more than the sum of its
> parts.

hmmmm... nobody has to *maintain* the mona lisa at least not the way
we have to *maintain* code. let alone *extend* it. i suspect you'll
have to pick a better metaphor.

:-)

[James O. Coplien]

Den 29 Apr 2014 kl. 19:41 skrev Raoul Duke <rao...@gmail.com>:

> hmmmm... nobody has to *maintain* the mona lisa at least not the way
> we have to *maintain* code. let alone *extend* it. i suspect you'll
> have to pick a better metaphor.

Busted.

:-)

[James O. Coplien]

Den 29 Apr 2014 kl. 19:41 skrev Raoul Duke <rao...@gmail.com>:

> hmmmm... nobody has to *maintain* the mona lisa at least not the way
> we have to *maintain* code. let alone *extend* it. i suspect you'll
> have to pick a better metaphor.

Un-busted.

http://www.lumiere-technology.com/Pages/News/news3.htm

[Jonah S]

Very cool.  Haven't had a chance to respond to the great replies to my earlier questions, but while on the subject of examples of the inseparability of whole and part, I thought I'd add that game theoretically optimal solutions to poker games exhibit this property in a fascinating way.  

You literally cannot solve for a specific situation (how should I play two aces preflop) without solving the entire game tree: your own hand ranges, your opponent's hand ranges, future actions and cards, and possible past actions are all inextricably intertwined.  This is why even relatively simple games like heads up limit holdem have not been solved (modern computing power still falls short by several orders of magnitude), although decent approximations have been made using iterative simulation methods such as counterfactual regret minimization.  

Jonah

[James O. Coplien]

Cool.  But way beyond my understanding. I reserve my gambling activities to Windows programming.

[Raoul Duke]

> You literally cannot solve for a specific situation (how should I play two
> aces preflop) without solving the entire game tree: your own hand ranges,
> your opponent's hand ranges, future actions and cards, and possible past

i strongly suspect this is a red herring and really doesn't say much
about being unable to further decompose code. it might say something
sometimes, but it doesn't outweigh all the other considerations one
must respect when coding.

[Jonah S]

I'm inclined to agree.  I just thought it was an interesting example of the subject at hand.

[Herman Peeren]

Is TDD dead? Google hangout, recorded on May 9 (yesterday) with David Heinemeier Hansson (DHH), Martin Fowler & Kent Beck https://www.youtube.com/watch?v=z9quxZsLcfo

Part 1 of 6. Not much related to the discussion here, but the discussion was inspired by DHH's keynote too

[James O. Coplien]

I think my unit testing article had a little to do with his talk, and that in turn was inspired in large part by DCI.

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Den 10/05/2014 kl. 17.55 skrev Herman Peeren <herman...@gmail.com>:

Is TDD dead? Google hangout, recorded on May 9 (yesterday) with David Heinemeier Hansson (DHH), Martin Fowler & Kent Beck https://www.youtube.com/watch?v=z9quxZsLcfo

Part 1 of 6. Not much related to the discussion here, but the discussion was inspired by DHH's keynote too

[Jonah S]

Cope,

From what I can tell, DHH is a fan of yours but ambivalent about DCI in general:

https://twitter.com/dhh/status/460521080294100992

http://signalvnoise.com/posts/3372-put-chubby-models-on-a-diet-with-concerns

Quote from above article:

"This approach to breaking up domain logic into concerns is similar in some ways to the DCI notion of Roles. It doesn’t have the run-time mixin acrobatics nor does it have the “thy models shall be completely devoid of logic themselves” prescription, but other than that, it’ll often result in similar logic extracted using similar names."

Some other relevant tweets on DCI:

https://twitter.com/dhh/status/460523666498142209

https://twitter.com/dhh/status/280744338923872256

https://twitter.com/dhh/status/280741416039219202

https://twitter.com/garybernhardt/status/280737828495826944 (longer discussion, not all relevant to DCI, but interesting)

I don't know if you watched the video yet, but they had to end just when the discussion was about to get meaty and rise above vague kumbaya generalisations about which everyone agrees.  They have another session planned for next week to continue where they left off.

I would really love to see you on that panel -- you should send them an email, I'm sure they'd be excited to have you.

[James O. Coplien]

Den 11/05/2014 kl. 11.44 skrev Jonah S <jona...@gmail.com>:

Cope,

From what I can tell, DHH is a fan of yours but ambivalent about DCI in general:

Yes, but the point is that there are some basic notions that are pretty universal and which fly in the face of convention. Though it's good to have DCI cheerleaders it's also good to have thoughtful people from other sectors broadly fertilizing the earth with tangentially powerful ideas.

I don't know if you watched the video yet, but they had to end just when the discussion was about to get meaty and rise above vague kumbaya generalisations about which everyone agrees.  They have another session planned for next week to continue where they left off.

I would really love to see you on that panel -- you should send them an email, I'm sure they'd be excited to have you.

What is the goal? That is, after the panel, how will the world be a better place?

Someone wrote to me about the DHH / Fowler / Beck panel and said he didn't have the patience to spend 30 minutes on a discussion that would go nowhere. I think that's a good assessment. I'd rather be outside any forum that sets itself up to have that reputation. If the folks are serious they would come together for a workshop and publish a joint work about the outcome. I could sign up for that. But panels are too much about theatre, and I'm a lousy actor.

[Jonah S]

"What is the goal? That is, after the panel, how will the world be a better place?"

Jonah would be more enlightened :)

On Sunday, May 11, 2014 5:47:11 AM UTC-5, Cope wrote:

Den 11/05/2014 kl. 11.44 skrev Jonah S <jona...@gmail.com>:

Cope,

From what I can tell, DHH is a fan of yours but ambivalent about DCI in general:

Yes, but the point is that there are some basic notions that are pretty universal and which fly in the face of convention. Though it's good to have DCI cheerleaders it's also good to have thoughtful people from other sectors broadly fertilizing the earth with tangentially powerful ideas.

I don't know if you watched the video yet, but they had to end just when the discussion was about to get meaty and rise above vague kumbaya generalisations about which everyone agrees.  They have another session planned for next week to continue where they left off.

I would really love to see you on that panel -- you should send them an email, I'm sure they'd be excited to have you.

What is the goal? That is, after the panel, how will the world be a better place?

Someone wrote to me about the DHH / Fowler / Beck panel and said he didn't have the patience to spend 30 minutes on a discussion that would go nowhere. I think that's a good assessment. I'd rather be outside any forum that sets itself up to have that reputation. If the folks are serious they would come together for a workshop and publish a joint work about the outcome. I could sign up for that. But panels are too much about theatre, and I'm a lousy actor.

> On Sunday, May 11, 2014 3:42:51 AM UTC-5, Cope wrote:

> I think my unit testing article had a little to do with his talk, and that in turn was inspired in large part by DCI.

> 

> 

> http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

> 

> 

> 

> Den 10/05/2014 kl. 17.55 skrev Herman Peeren <herman...@gmail.com>:

> 

> Is TDD dead? Google hangout, recorded on May 9 (yesterday) with David Heinemeier Hansson (DHH), Martin Fowler & Kent Beck https://www.youtube.com/watch?v=z9quxZsLcfo 

> 

> Part 1 of 6. Not much related to the discussion here, but the discussion was inspired by DHH's keynote too

> 

> -- 

> You received this message because you are subscribed to the Google Groups "object-composition" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

> To post to this group, send email to object-co...@googlegroups.com.

> Visit this group at http://groups.google.com/group/object-composition.

> For more options, visit https://groups.google.com/d/optout.

> 

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[Risto Välimäki]

2014-05-11 11:42 GMT+03:00 James O. Coplien <jcop...@gmail.com>:

I think my unit testing article had a little to do with his talk, and that in turn was inspired in large part by DCI.

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Thank a lot for this Cope, and for your own article about unit testing as well.

DHH wrote something I have always thought, but the "church of TDD" has been way too strong and I have been sometimes treated as an infidel. Now I can just say that "don't take my word, but check what DHH says".

Article by DHH is a more powerful hammer to use than yours, since unlike you (I suppose), DHH has been an advocate of TDD.

Maybe the most negative side of the TDD was that -- not very long ago -- you were not regarded as a professional, if you weren't a TDD-advocate.

-Risto

[James O. Coplien]

Den 05/06/2014 kl. 17.30 skrev Risto Välimäki <risto.v...@gmail.com>:

2014-05-11 11:42 GMT+03:00 James O. Coplien <jcop...@gmail.com>:

I think my unit testing article had a little to do with his talk, and that in turn was inspired in large part by DCI.

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Thank a lot for this Cope, and for your own article about unit testing as well.

Working on Chapter 2 :-)

DHH wrote something I have always thought, but the "church of TDD" has been way too strong and I have been sometimes treated as an infidel. Now I can just say that "don't take my word, but check what DHH says".

There is far, far too much of that going on in our industry, and far, far too much of it traces back to XP. This is a church that has been about money and, to some degree, power, while posing as a church in the name of truth. I have been finding it more and more disgusting over the years.

Article by DHH is a more powerful hammer to use than yours, since unlike you (I suppose), DHH has been an advocate of TDD.

In that sense, yes. I think there are strengths to each of our approaches but it's hard to accuse DHH of having a conflict of interest given that, as you say, he's a self-admitted former member of the flock...

Maybe the most negative side of the TDD was that -- not very long ago -- you were not regarded as a professional, if you weren't a TDD-advocate.

Oh, I'm sure that some — like Uncle Bob — still say that (at least if you are in the right audience listening to him — I think he says the opposite to other audiences. Never could figure that out.)

[Raoul Duke]

> Oh, I'm sure that some — like Uncle Bob — still say that (at least if you
> are in the right audience listening to him — I think he says the opposite to
> other audiences. Never could figure that out.)

i don't know if he does or not switch it up, but if so, well, he did
used to be a preacher? spitting distance from snake oil salesman ;-)
from my vantage point since i'm a dyed in the wool atheist.
(half-hearted apologies to any of those i've just really offended.)