[VIDEO] David West: OOP is Dead

[Anthony Green]

Earlier this year Steve arranged for Professor David West, author of Object Thinking, to come and give a talk at the BBC.

I've managed to get hold of a copy of the video of that talk and to upload it to Vimeo:

https://vimeo.com/77415896

[Raoul Duke]

i don't understand what he means by saying every java class is a
program with a main(). i also don't understand why he claims
javascript has classes. there's probably other things i won't grok.
:-)

[Raoul Duke]

...like: i would expect the rules thing that 'couldn't be done' would
best be tried in a lisp. and i find the claim that tdd is only good
when there are lots of lines of code odd, because to me it is more
about state space than about lines of code.

[Manuel Paccagnella]

Anthony, you have just become one of my heroes :) Thank you very much!

[Nat Pryce]

He doesn't say that.  He says that (paraphrased) every Java program starts with a thread of control running a main method, and you program by writing a main method to do something, and breaking down what it does into subordinate procedures and/or classes and objects.

Compare with a Smalltalk program in which there are lots of objects *already running*. Some of those objects translate between Smalltalk messages and hardware interrupts, for input, or control registers, for output, (usually via the OS these days). You program by modifying objects that are already running or creating new ones, and make your program do I/O by connecting your objects to those that interface with the hardware.

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
http://www.natpryce.com

[Douglas Waugh]

Does anybody know which books he's talking about by David Taylor (at 52:29) concerning metaphors?

[Alfredo Casado]

This style is more similar to the actor's models we can see in languages like erlang or scala (scala integrated akka actors model in the language in the last versions). Each object/actor have data, behavior and its own running thread, this actors/objects receives messages asynchronously and this enforces a tell don't ask style. It's difficult to think in this style when we use languages in which "sending a message to an object" its more "calling a function with implicit state".

Perhaps have each object in his own individual thread it's too much (think in a java program and each string having its own thread). How do you think about mix this style with functional decomposition or with "C++/java/etc" object oriented decomposition?, i see the actors/objects like element bigger than objects, and i don't sure if the typical rules or principles we apply like SRP can be applied to actors or we need to redefine those principles.

2013/10/22 Nat Pryce <nat....@gmail.com>

[isaiah perumalla]

i think he is referring to this book http://www.amazon.com/Object-Technology-A-Managers-Guide/dp/0201309947 .

its a short but interesting book, advocates "the mystical view of OO"

Isaiah Perumalla

[Nat Pryce]

It's nothing to do with threads.  Smalltalk has reactive objects, not active (actor-like) objects.

The distinction that David West is drawing is between a program having a single entry point that delegates control to sub-modules, and between a program being a collaborating web of live objects that are sending messages to one another and that you modify to define system behaviour.

As Kevlin Henney has put it, you *can* do object-oriented programming in Java, but it does take some effort.

--Nat

[J. B. Rainsberger]

On Tue, Oct 22, 2013 at 10:36 AM, Nat Pryce <nat....@gmail.com> wrote:

 

The distinction that David West is drawing is between a program having a single entry point that delegates control to sub-modules, and between a program being a collaborating web of live objects that are sending messages to one another and that you modify to define system behaviour.

Isn't the former simply a way of using the latter? I guess I don't understand the significance of the difference. So what? Even if I embed my objects within an already-running web of live objects, I'm likely going to do one of two things: (1) introduce new entry paths for data (fields in a form, repl) or (2) connect new listeners to existing/running entry paths for data (intercept or tap into requests sent to existing processes/objects/memory addresses). I program the same way in both cases. Und? (Not rhetorical. I'd like the understand this distinction he finds significant enough to make.)

-- 

J. B. (Joe) Rainsberger :: http://www.myagiletutor.com :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com

[Nat Pryce]

I think the distinction he's making is that it takes effort to program the same way when programming in Java.  The grain of the language is, at first, entirely procedural.  You have to expend effort to organise the system into collaborating objects.  In Smalltalk, the grain of the language is the other way: you have to expend effort to organise a program in the procedural style he describes.

--Nat

--

 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
http://www.natpryce.com

[Alastair Smith]

> I think the distinction he's making is that it takes effort to program the same way when programming in Java.  The grain of the language is, at first, entirely procedural.  You have to expend effort to organise the system into collaborating objects.  In Smalltalk, the grain of the language is the other way: you have to expend effort to organise a program in the procedural style he describes.

Is that the case? The code examples that David West displayed near the beginning included "Smalltalk from a Pascal programmer", which suggests to me that it's just as easy to program procedurally in Smalltalk as it is Java, C#, etc. IMHO the problem is more one of adopting the right mindset - thinking in terms of behaviours and messages, rather than flow of execution - and that will cut across all languages. 

Alastair

---

Date: Tue, 22 Oct 2013 17:24:59 +0100
Subject: Re: [GOOS] [VIDEO] David West: OOP is Dead
From: nat....@gmail.com
To: growing-object-o...@googlegroups.com

[J. B. Rainsberger]

On Tue, Oct 22, 2013 at 1:24 PM, Nat Pryce <nat....@gmail.com> wrote:

I think the distinction he's making is that it takes effort to program the same way when programming in Java.  The grain of the language is, at first, entirely procedural.  You have to expend effort to organise the system into collaborating objects.  In Smalltalk, the grain of the language is the other way: you have to expend effort to organise a program in the procedural style he describes.

OK; as I thought. I still don't see the connexion to OOP being dead or not, but I'm glad that I'm not missing anything terribly significant in this one point. :) Thanks.

-- 

[J. B. Rainsberger]

On Tue, Oct 22, 2013 at 1:32 PM, Alastair Smith <alas...@alastairsmith.me.uk> wrote:

 

> I think the distinction he's making is that it takes effort to program the same way when programming in Java.  The grain of the language is, at first, entirely procedural.  You have to expend effort to organise the system into collaborating objects.  In Smalltalk, the grain of the language is the other way: you have to expend effort to organise a program in the procedural style he describes.

Is that the case? The code examples that David West displayed near the beginning included "Smalltalk from a Pascal programmer", which suggests to me that it's just as easy to program procedurally in Smalltalk as it is Java, C#, etc. IMHO the problem is more one of adopting the right mindset - thinking in terms of behaviours and messages, rather than flow of execution - and that will cut across all languages. 

I don't find the grain particularly strong in either direction, but if you could have asked me 15 years ago, I'd probably respond differently. For me, TDD made all the difference, and not Java v. Smalltalk.

-- 

[Nat Pryce]

I meant the large-scale procedural style he described: top-down down decomposition of a program with a single entry point and a controlling "master control module" (I think he called it - is that a term from JSP?). 

Java programs have a single entry point, and that entry point has to define & create all the objects that interface to the outside world. A Smalltalk program doesn't have a single entry point in that way.

--Nat

www.natpryce.com

[Evgeni Dzhelyov]

Is that Steve who asked the question about the complexity moved to the collaboration of the objects ?

I don't really like West's answer, it's too vague. In my opinion the complexity in the real world is not as comprehensible as he described it. Even in his own example, with all these strange rules you have to apply to the formatting of a document, it will be difficult to be sure the system works as expected in all cases.

I think you need an automated way to verify the behavior of the system just to be sure it is working as expected and you need that for every system of significant importance. What I really like in Kent Beck's ideas is that he acknowledges the fact that people make mistakes and need to find a way to minimize those mistakes. TDD in it's essence is just that - a technique that minimize the unconscious mistake we are going to make while programming. I have the feeling that David West overestimate our ability to think flawlessly which in reality is quite the opposite.

I think the question about the complexity being moved from the code to the collaboration of the objects is a valid and important one.

In a procedural program you can read the code and see the connections there, while in the OO one you need to understand the current objects graph structure. How you deal with that complexity and delegation ? I don't know of any other way than having automated test  ...

A side question: What he describes as behavior oriented design, is that the opposite of what Rich Hickey says about concentrating your model around the data structures ? Are these ideas completely different or I'm missing something ?

--

[Nat Pryce]

I have to say, I found his argument that <<if you have no methods longer that 3 lines you don't need testing because err... mother nature>> entirely unconvincing. (Was it a response to a question from Steve F?)

For one thing it ignores the power law distribution of method sizes that has been found in empirical studies of real software. It also conveniently ignored the fact that humans don't understand how nature works! 

Is that all we can hope for -- we understand what a three line method is intended to do but the behaviour of the system as a whole can only be approximated via the scientific method?

--Nat

www.natpryce.com

--

[Raoul Duke]

> I have the feeling that David West overestimate our ability to think flawlessly which in reality is quite the opposite.

there are some people who can hold the whole thing in their head and
get it mostly right. they are rare. there are more people who /think/
they can hold the whole thing in their head and get it mostly right,
but they don't. they are less rare. then there's the rest of us. i'm
not sure what Dr. West is like :-)

[Raoul Duke]

> A side question: What he describes as behavior oriented design, is that the
> opposite of what Rich Hickey says about concentrating your model around the
> data structures ? Are these ideas completely different or I'm missing
> something ?

this is an on-going feud. why can't we all get along? "mu!"

(a) http://lists.racket-lang.org/users/archive/2010-April/038935.html

(b) http://www.artima.com/forums/flat.jsp?forum=226&thread=253008

(c) http://www.scottish-history.com/glencoe.shtml

[dave west]

Dave West chiming in

I almost never visit my google mail, so I have not seen this conversation.  If anyone has questions, send them to me at profwest@ fastmail.fm and I will be happy to reply - you can then post the responses to the list if they seem worthwhile.  (I will also try to use my google email more often and enter the discussion directly.)

Some comments:
the Taylor book is A. David Taylor, Business Engineering with OO Technology - it is similar to the manager's guide but does a much better job of showing object decomposition of a business and makes a better case for the claim that everything is an object.

a major theme of the video is the fact that objects were "ruined and made irrelevant" because they fell into the hands of programmers (including Alan Kay) and objects have little, if any, value as a programming concept.  Because all the arguments about objects occurred in the context of programming they focused on things that really don't matter much, like single versus multiple inheritance, dot notation versus explicit messages for getting and setting or invoking methods; class hierarchies, friends, even the idea of a class.

In the early 90s when OO programming as ascendant - destined to be the "next COBOL" in popularity - thousands of existence proofs showed that programs could be written in Smalltalk in a third of the time, with an order of magnitude fewer lines of code, less complexity of the code, etc. etc.  The problem was that none of these unquestionable results had anything to do with the programming language.  95% of the results were attributable to design.

Objects lead to more accurate understandings of complex domains and better and simpler designs, which when implemented are extraordinarily simple - the programming tends to become trivial.

The rant against java - and the fact that if you decide to create a class - the class structure demands a main() with, usually, typed instance variables, and subroutines for each method.  Without being given the opportunity to reflect or find alternatives, programmers are forced into thinking about their programs, and their objects, as tiny instances of the 1950s model of program architecture called a "Program Structure Chart" with its master control module, afferent, efferent, and transform modules (all subtroutines) called at the discretion of the master control module.  This causes all kinds of conflict - conflict exceeded only by trying to force fit object software into a relational database.  You can have the most elegant of solutions and design for an implementation only to find yourself unable to express it directly and easily in Java.

I am very flattered to have been asked to go to the BBC and that some of you have expressed an interest in what I was saying (or trying to say).

davew

[Herman Peeren]

Simula was my first OO-language. It was in the seventies and I was struck by its power of defining relatively simple objects that interacted. We used it to simulate for instance how traffic jams originated. Or model economic or environmental processes. Those models could be used for predictions.

There were several possible (interrelated) ways to look at the problem:
- mathematical, defining functions of length of road, number of cars, number of exits, weather, etc. These functions tend to be rather complex, especially because there are several functions between variables operating at the same time.
- statistical, mainly using regression to get the parameters for the above mentioned functions
- and we could simulate, model the problem with a computer (still using punchcards in those days...)

The behaviour of objects (like cars; which included the driver of course) was modeled with Simula. Each object had a behaviour that was not complex. Maximum speed; accelleration; how much to slow down when you see brake lights in front of you at x meters; how much slower you drive in case of rain; etc.

All relevant information is not modeled as data on the system level, but as behaviour on the object level.

That did the trick. Complexity vanished. Not because the complexity was moved to the collaboration of objects, but because the complexity was only introduced by trying to "program" the system as a whole, with all the processes that influence each other. At the object level, things are relatively simple.

This still doesn't say much about testing, where this list is all about. But maybe it contributes something to thinking about objects. BTW, I personally prefer the word "modeling" above "design"; to avoid confusion with the way output is styled.

- Herman

[Nat Pryce]

On 23 October 2013 09:13, Herman Peeren <herman...@gmail.com> wrote:

This still doesn't say much about testing, where this list is all about.

This listing is not all about testing. GOOS is a book about OO design, not testing, so it's fine to talk about design or modelling on this list.

--Nat

 

On Monday, 21 October 2013 19:28:19 UTC+2, Anthony Green wrote:

Earlier this year Steve arranged for Professor David West, author of Object Thinking, to come and give a talk at the BBC.

I've managed to get hold of a copy of the video of that talk and to upload it to Vimeo:

https://vimeo.com/77415896

--

 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
http://www.natpryce.com

[Herman Peeren]

On Wednesday, 23 October 2013 10:46:59 UTC+2, Nat wrote:

This listing is not all about testing. GOOS is a book about OO design, not testing, so it's fine to talk about design or modelling on this list.

 OK, Nat, thanks. Good to know.

Talking about OO modeling, here is something else I'm playing around with at the moment: DCI, Data-Context-Interaction. It is based on separating the behaviour of different roles in a context (use case) from the objects. Complexity decreases by a better and more granular division of responsibilities over objects.

James Coplien calls the way we develop now: class oriented, not object oriented. He and Trygve want to go back to objects. That is also related to what David West talks about in the video.

Some links:

• http://en.wikipedia.org/wiki/Data,_context_and_interaction
• http://www.artima.com/articles/dci_vision.html
• http://architects.dzone.com/videos/dci-architecture-coplien
• http://heim.ifi.uio.no/~trygver/themes/babyide/babyide-index.html

[Evgeni Dzhelyov]

I still think that complexity in real world systems can be quite high. In Herman's traffic jam example, there is difference in how complex a system with 2 cars and one light will be and with 1000 cars and 10 lights.

Of course, we want to minimize the accidental complexity in our modeling, but still there is varying complexity in the real world.

Let's say I have object A with 2 possible behaviors and object B also with 2. When I connect A to B it means that the behavior of the system they represent have 4 possible paths. In reality, I never cared about object A and B individually, but only about the system their compose. How do I know that the system(AB) works ?

I don't think it's enough to look into A, look into B and say: "this things works, so the system will work". What about when you have 1,000 objects that communicate ?

My current understanding is that West's point is that if you minimize accidental complexity to 0 your system will be simple enough for you understand. Maybe because you need to understand it, in order to build the model in the first place.

I've never worked with programs with low accidental complexity and it's difficult for me to buy on that argument, but maybe he is right, I'm not sure ...

We can only build as good program as our current understanding for the real system, is that right ?

[Anthony Green]

This listing is not all about testing. GOOS is a book about OO design, not testing, so it's fine to talk about design or modelling on this list.

A point I've heard both you and Steve make on a number of occasions. I'm not sure what leads so many people to the conclusion it's about  testing, I didn't get my impression reading it. I wonder what's missing from people's experience... perhaps the extended 'web' of affiliated ideas.

[Nat Pryce]

On 23 October 2013 10:56, Anthony Green <anthony.ch...@gmail.com> wrote:

This listing is not all about testing. GOOS is a book about OO design, not testing, so it's fine to talk about design or modelling on this list.

A point I've heard both you and Steve make on a number of occasions. I'm not sure what leads so many people to the conclusion it's about  testing, I didn't get my impression reading it. I wonder what's missing from people's experience... perhaps the extended 'web' of affiliated ideas.

I think it's the title.  For some reason, the concept of "test" is understood very differently by programmers than by "normal" people, and if the word appears in a sentence it's as if it is in 500pt multicoloured bold italic capitals with  marching ants, blink tag and marquee effects applied -- programmers notice the word "test" first and immediately become unable to parse the rest of the text

Case in point - test-driven development.  Development is the noun.  Test-driven is an adjectival clause.  It' not a testing technique, but you wouldn't know that from looking at academic research into TDD.

That's why we called the book "Growing Object-Oriented Software Guided by Tests".  We hoped people would realise that the book was about growing Object-Oriented software.  But our hopes were soon dashed.

 

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
http://www.natpryce.com

[Herman Peeren]

Sorry for the misunderstanding, but the summary of the GOOS-book (at the back) has the acronym TDD in almost every sentence and the word "test" is in more than half of the chapter titles. The book is about Test Driven Development, as is also stated in the preface. I had the impression that that had something to do with tests.

It coul be a matter of emphasis and maybe I can summarise it as: GOOS puts more emphasis on the last D (Development/ Design) than the T (Test).

[Steve Tooke]

On 23 October 2013 11:22, Nat Pryce <nat....@gmail.com> wrote:

On 23 October 2013 10:56, Anthony Green <anthony.ch...@gmail.com> wrote:

This listing is not all about testing. GOOS is a book about OO design, not testing, so it's fine to talk about design or modelling on this list.

A point I've heard both you and Steve make on a number of occasions. I'm not sure what leads so many people to the conclusion it's about  testing, I didn't get my impression reading it. I wonder what's missing from people's experience... perhaps the extended 'web' of affiliated ideas.

I think it's the title.  For some reason, the concept of "test" is understood very differently by programmers than by "normal" people, and if the word appears in a sentence it's as if it is in 500pt multicoloured bold italic capitals with  marching ants, blink tag and marquee effects applied -- programmers notice the word "test" first and immediately become unable to parse the rest of the text

Case in point - test-driven development.  Development is the noun.  Test-driven is an adjectival clause.  It' not a testing technique, but you wouldn't know that from looking at academic research into TDD.

That's why we called the book "Growing Object-Oriented Software Guided by Tests".  We hoped people would realise that the book was about growing Object-Oriented software.  But our hopes were soon dashed.

This discussion reminds me of something:

https://www.dropbox.com/s/c02otwttlw0r3e7/BDD-Intro.pdf

(Dave Astels - 2005)

 

Steve Tooke :: heavi.es

+44 7919 337 463 :: +44 20 8133 4134

skype:stevetooke :: twitter.com/tooky

Heavies Limited

Registered Number: 7612561

Registered Address: Parmenter House, 57 Tower Street, Winchester SO23 8TD

[J. B. Rainsberger]

On Tue, Oct 22, 2013 at 2:32 PM, Nat Pryce <nat....@gmail.com> wrote:

 

I meant the large-scale procedural style he described: top-down down decomposition of a program with a single entry point and a controlling "master control module" (I think he called it - is that a term from JSP?). 

I know it as Front Controller.

 

Java programs have a single entry point, and that entry point has to define & create all the objects that interface to the outside world. A Smalltalk program doesn't have a single entry point in that way.

It does and it doesn't. Maybe. I write a program in Smalltalk. I have to run it somehow. I either connect it to some already-running object that provides it stimuli or I make a new front controller available to the world outside the Smalltalk environment. I suppose the former option doesn't quite exist in Java.

Maybe as soon as I say "I write a program in Smalltalk" I have it wrong. I was raised on procedural languages. Even if I just "add objects to a live environment", I have to somehow connect those objects to stimuli to make them do anything. To me, this is either "running the program" or "plugging into a framework", both things I do the same way in Java and in Smalltalk.

Right now I can't tell whether I don't get it at all or I get it so much that I can't see what there is to get. I suspect it's one or the other.

-- 

[J. B. Rainsberger]

On Tue, Oct 22, 2013 at 9:27 PM, dave west <profw...@gmail.com> wrote:

 

Dave West chiming in

Thanks, Dave.

The rant against java - and the fact that if you decide to create a class - the class structure demands a main() with, usually, typed instance variables, and subroutines for each method.  Without being given the opportunity to reflect or find alternatives, programmers are forced into thinking about their programs, and their objects, as tiny instances of the 1950s model of program architecture called a "Program Structure Chart" with its master control module, afferent, efferent, and transform modules (all subtroutines) called at the discretion of the master control module.

I feel stuck here. I use "web of objects" as a way to organise behavior sensibly, which has clear advantages in pluggability and modularity, but I do still think in terms of "programs", which I start and stop as needed, just like I start and stop jobs on my operating system. I just don't see the restriction in this way of thinking, so either I'm blind or there's really no problem. :)

This causes all kinds of conflict - conflict exceeded only by trying to force fit object software into a relational database.  You can have the most elegant of solutions and design for an implementation only to find yourself unable to express it directly and easily in Java.

In Java in particular, or in any programming environment whose dominant model involves a main() routine?

 

I am very flattered to have been asked to go to the BBC and that some of you have expressed an interest in what I was saying (or trying to say).

I appreciate your interest in our conversation.

-- 

[J. B. Rainsberger]

On Wed, Oct 23, 2013 at 5:13 AM, Herman Peeren <herman...@gmail.com> wrote:

All relevant information is not modeled as data on the system level, but as behaviour on the object level.

That did the trick. Complexity vanished. Not because the complexity was moved to the collaboration of objects, but because the complexity was only introduced by trying to "program" the system as a whole, with all the processes that influence each other. At the object level, things are relatively simple.

This matches my experience, limited as it is, that complications have come not from the domain, but from attempting to connect domain objects to the ugly outside world of screens and prompts and files and databases and web services.

-- 

[J. B. Rainsberger]

On Wed, Oct 23, 2013 at 6:42 AM, Evgeni Dzhelyov <evgeni....@gmail.com> wrote:

 

My current understanding is that West's point is that if you minimize accidental complexity to 0 your system will be simple enough for you understand. Maybe because you need to understand it, in order to build the model in the first place.

For this exact reason, I practise TDD. TDD gives me two opportunities to lower accidental complication (not complexity) every time around the cycle. Writing the test first encourages me not to add accidental complication and the refactoring step encourages me to reduce accidental complication. I find that, even with objects, TDD has nudged me in the direction of highly-pluggable functional-style designs.

We can only build as good program as our current understanding for the real system, is that right ?

That makes sense to me.

-- 

[J. B. Rainsberger]

On Wed, Oct 23, 2013 at 3:13 PM, J. B. Rainsberger <m...@jbrains.ca> wrote:

 

In Java in particular, or in any programming environment whose dominant model involves a main() routine?

Ah, yes… I meant to add this:

I see the main() routine as Just One Way to export my web of objects to the outside world. Another way involves embedding them in some existing framework. By my understand, Smalltalk really only gives us (or at least encourages us in the direction of) the latter.

-- 

[Angel Java Lopez]

+100 to TDD and its opportunities. TDD pushes me towards a simple design that can evolve and be shared

But I a bit lost.. difference btw complication and complexity in English? For example, Rick Hickey usually talks about "incidental complexity" https://www.simple-talk.com/opinion/geek-of-the-week/rich-hickey-geek-of-the-week/

--

[J. B. Rainsberger]

On Wed, Oct 23, 2013 at 3:37 PM, Angel Java Lopez <ajlop...@gmail.com> wrote:

 

But I a bit lost.. difference btw complication and complexity in English? For example, Rick Hickey usually talks about "incidental complexity" https://www.simple-talk.com/opinion/geek-of-the-week/rich-hickey-geek-of-the-week/

I use the terms in a similar way to the Cynefin model. https://en.wikipedia.org/wiki/Cynefin

"Complicated": we can understand it, but that requires significant tedious effort.

"Complex": we can't understand it all, no matter how much effort we put in.

Most software designs are "complicated" (lots of parts), but not "complex", because they don't have emergent behavior. Runtime environments are often complex because the behavior of the various parts changes over time.

-- 

[Herman Peeren]

I normally use 'complex' for something that is composed of parts, put together. I use 'complicated' for something that is not easy to understand.

I cannot imagine anything useful with your definition of 'complex'; it reminds me of the last proposition of Wittgenstein's Tractatus: Wovon man nicht sprechen kann, darüber muss man schweigen. (“Whereof one cannot speak, thereof one must be silent.”).

[J. B. Rainsberger]

On Wed, Oct 23, 2013 at 4:15 PM, Herman Peeren <herman...@gmail.com> wrote:

 

I normally use 'complex' for something that is composed of parts, put together. I use 'complicated' for something that is not easy to understand.

Yes, I've seen that, too.

 

I cannot imagine anything useful with your definition of 'complex'; it reminds me of the last proposition of Wittgenstein's Tractatus: Wovon man nicht sprechen kann, darüber muss man schweigen. (“Whereof one cannot speak, thereof one must be silent.”).

What did you intend by this comment?

-- 

[Herman Peeren]

On Wednesday, 23 October 2013 21:32:20 UTC+2, J. B. Rainsberger wrote:

What did you intend by this comment?

Nothing nasty or unfriendly, of course. Just that for me your definition of complex ("we can't understand it all, no matter how much effort we put in") doesn't seem very useful and might be a symptom of this: if we cannot answer a question or solve a problem, then the question might be wrong or the problem wrongly stated. And that is, in my interpretation, exactly what Wittgenstein wanted to point out, hence the quotation. Back to modeling: the goal must be to simplify things, often by just leaving out a lot of other things. For me the basic idea of OOP (or should I say OOM: Object Oriented Modeling) is to simplify things by decomposing the compexity to 'simple' (as opposed to complex) objects.

[Steve Freeman]

To be precise, complex means that there's no direct relationship between cause and effect. We can't repeat an action and predict exactly what's going to happen. That doesn't mean we have nothing to say about a system or that we can't work with it, it just requires different techniques.

Chaotic is another matter altogether (although maybe this terminology has changed by now).

S

[Steve Freeman]

A significant difference is the smalltalk idea of living in a soup of objects. It actually requires effort to extract a "program" from a smalltalk image.

S. 

Sent from a device without a keyboard. Please excuse brevity, errors, and embarrassing autocorrections. 

--

[Steve Freeman]

Buried under the ranting Coplien does make some good points about the general state of the art. That said, some of us have been trying to carry the torch for proper objects. And what I've been able to understand about their approach reminds me of C# extension methods. 

S. 

Sent from a device without a keyboard. Please excuse brevity, errors, and embarrassing autocorrections. 

[J. B. Rainsberger]

On Wed, Oct 23, 2013 at 4:47 PM, Herman Peeren <herman...@gmail.com> wrote:

On Wednesday, 23 October 2013 21:32:20 UTC+2, J. B. Rainsberger wrote:

What did you intend by this comment?

Nothing nasty or unfriendly, of course.

It didn't seem that way to me at first look, which is why I asked.

 

Just that for me your definition of complex ("we can't understand it all, no matter how much effort we put in") doesn't seem very useful[…]

…except as a reminder not to waste our time trying to understand it all before trying to interact with it. People do try to do that. :) Similarly, Gödel's work discourages otherwise well-meaning people from spending their lives trying to axiomatise mathematics.

 

...and might be a symptom of this: if we cannot answer a question or solve a problem, then the question might be wrong or the problem wrongly stated. And that is, in my interpretation, exactly what Wittgenstein wanted to point out, hence the quotation.

 That sounds reasonable to me.

 

Back to modeling: the goal must be to simplify things, often by just leaving out a lot of other things. For me the basic idea of OOP (or should I say OOM: Object Oriented Modeling) is to simplify things by decomposing the compexity to 'simple' (as opposed to complex) objects.

I see that as the idea of modular design in general, not just specifically OOM/P. OOM/P certainly seems to involve a combination of decomposition and abstraction, using "shares the same pieces of data" as an organising mechanism for behavior.

-- 

[Herman Peeren]

On Thursday, 24 October 2013 21:08:29 UTC+2, J. B. Rainsberger wrote:

…except as a reminder not to waste our time trying to understand it all before trying to interact with it. People do try to do that. :) Similarly, Gödel's work discourages otherwise well-meaning people from spending their lives trying to axiomatise mathematics.

Welcome to the OO philosophy list... ;-) Seriously, what I like about software development is that we are modeling pieces of the "real" world. That means that we are abstracting what  we see around us, forming ideas about it. We sometimes even have to invent new words to express the models. In that way, modeling IS philosophy. For me Gödels theorems don't discourage axiomatisation, but only show that the set of axioms can never be complete. New axioms can always be made, that cannot be derived from the allready existing set of axioms. For me that means: creativity is endless! You can always come up with something new. For modeling it means: we can always extend our models, build new software, create new things. So for me it sounds a bit strange to hear that Gödel's work would discourage some people to do something, as it has exactly the opposite effect on me.

 On Thursday, 24 October 2013 21:08:29 UTC+2, J. B. Rainsberger wrote:

On Wed, Oct 23, 2013 at 4:47 PM, Herman Peeren wrote:
Back to modeling: the goal must be to simplify things, often by just leaving out a lot of other things. For me the basic idea of OOP (or should I say OOM: Object Oriented Modeling) is to simplify things by decomposing the compexity to 'simple' (as opposed to complex) objects.

I see that as the idea of modular design in general, not just specifically OOM/P. OOM/P certainly seems to involve a combination of decomposition and abstraction, using "shares the same pieces of data" as an organising mechanism for behavior.

Yes, that too. But a point I want to make is that some complexity will disappear by the decomposition, because when many things happen at the same time, it is hard to predict the overall result. But at the object-level things can be very simple. Just like with the brain: when you are looking at that marvelous system as a whole, it is hard to tell what exactly happens, Yet on the level of separate neurons, behaviour is relatively somple. So I can imagine the question: are we putting the complexity in the interaction between the neurons? No, that is still simple too. Interesting.

The discussion about the main()-object made me think of The Game of Life, that many of us use in training/katas. You can program it in such a way, that all cells are acting as individual objects, like a neuron does in the brain: no central main()-object that manages them, but just being notified by their neighbours that they are alive and when enough neighbours have done so, that cell will be alive; otherwise it dies. Those objects are in the soup together, all equally reacting to their environment. Not as "subroutines", but as if they are a tribe of some kind of living individuals. It is that kind of concurrency that is harder to do in Java than in some other languages (but of cource not impossible, as we all  computer-languages operate on some sort of Turing Machine). In so far the Sapir/Whorf hypothesis, that the use of different languages at least influences our thinking in a bit different way, is probably even more true for computer languages.

 

[J. B. Rainsberger]

On Thu, Oct 24, 2013 at 8:07 PM, Herman Peeren <herman...@gmail.com> wrote:

On Thursday, 24 October 2013 21:08:29 UTC+2, J. B. Rainsberger wrote:

…except as a reminder not to waste our time trying to understand it all before trying to interact with it. People do try to do that. :) Similarly, Gödel's work discourages otherwise well-meaning people from spending their lives trying to axiomatise mathematics.

Welcome to the OO philosophy list... ;-) Seriously, what I like about software development is that we are modeling pieces of the "real" world. That means that we are abstracting what  we see around us, forming ideas about it. We sometimes even have to invent new words to express the models. In that way, modeling IS philosophy. For me Gödels theorems don't discourage axiomatisation, but only show that the set of axioms can never be complete. New axioms can always be made, that cannot be derived from the allready existing set of axioms. For me that means: creativity is endless! You can always come up with something new. For modeling it means: we can always extend our models, build new software, create new things. So for me it sounds a bit strange to hear that Gödel's work would discourage some people to do something, as it has exactly the opposite effect on me.

When I wrote "…axiomatise mathematics", I meant completely, because otherwise, it's not axiomatised. :) (Just how I meant the words.) One might still try to see how close one can get to complete, to seek patterns in the gap to completeness, and one can certainly enjoy the pursuit, but if one intends to axiomatise mathematics completely, then one needs a new hobby. :)

-- 

[Herman Peeren]

On Friday, 25 October 2013 08:51:46 UTC+2, J. B. Rainsberger wrote:

When I wrote "…axiomatise mathematics", I meant completely, because otherwise, it's not axiomatised. :) (Just how I meant the words.)

I appreciate you taking the trouble to answer, but in my not so humble opinion that is a rather nonsensical sentence:

• "mathematics" as a whole can not be axiomatised; that doesn't mean anything. You axiomatise a specific domain. Like you model a domain and don't model "computer science".
• axiomatising a domain is to make up a set of axioms (that is: "production rules" or "rules of the game"). That can never be "complete" (meaning: there can always be new rules made up that are not derivable from the old rules), so why would you define to axiomatise as to "completely" axiomatise? That makes no sense.

To axiomatise a domain is to set rules for a game. The rules can never be "complete" (that is what Gödel proved), but the game is still useful. A model is exactly the same: it is a set of rules for a game. You make rules that describe the domain (the game). You can always make up more rules and extend the model. But that doesn't reduce the usefulness of the limited model or game.

 

[J. B. Rainsberger]

Please condescend more to me. I enjoy it.

-- 

[Herman Peeren]

On Friday, 25 October 2013 14:13:32 UTC+2, J. B. Rainsberger wrote:

Please condescend more to me. I enjoy it.

I'm not a native English speaker, so I probably won't get all connotations and subtle associations with words like "condescend".  Please be assured I estimate you high and want to learn a lot from any dialogue, as I do from this one too. That is the only reason we will all put effort in it and it will bring us all further. I enjoyed reading your remarks here and elsewhere too.

Cheers,
Herman

[Raoul Duke]

yeah, I didn't read Herman as being annoying, more just trying to
bridge a gap, for whatever it is worth. & i do love learning from Mr.
Rainsberger.

[philip schwarz]

Hello Anthony, 

I don't see a download button for the video. I would really appreciate it if it were downloadable (though I fully understand if there are reasons why that is not possible).

Philip

[philip schwarz]

>its a short but interesting book, advocates "the mystical view of OO"

ordered!

Philip

On Tuesday, 22 October 2013 13:59:00 UTC+1, isaiah perumalla wrote:

i think he is referring to this book http://www.amazon.com/Object-Technology-A-Managers-Guide/dp/0201309947 .

its a short but interesting book, advocates "the mystical view of OO"

On Tue, Oct 22, 2013 at 1:52 PM, Douglas Waugh <douglas....@gmail.com> wrote:

Does anybody know which books he's talking about by David Taylor (at 52:29) concerning metaphors?

On 22 October 2013 12:00, Nat Pryce <nat....@gmail.com> wrote:

He doesn't say that.  He says that (paraphrased) every Java program starts with a thread of control running a main method, and you program by writing a main method to do something, and breaking down what it does into subordinate procedures and/or classes and objects.

Compare with a Smalltalk program in which there are lots of objects *already running*. Some of those objects translate between Smalltalk messages and hardware interrupts, for input, or control registers, for output, (usually via the OS these days). You program by modifying objects that are already running or creating new ones, and make your program do I/O by connecting your objects to those that interface with the hardware.

On 21 October 2013 19:13, Raoul Duke <rao...@gmail.com> wrote:

i don't understand what he means by saying every java class is a
program with a main(). i also don't understand why he claims
javascript has classes. there's probably other things i won't grok.
:-)

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

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

For more options, visit https://groups.google.com/groups/opt_out.

--
http://www.natpryce.com

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

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

For more options, visit https://groups.google.com/groups/opt_out.

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

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

For more options, visit https://groups.google.com/groups/opt_out.

--
Isaiah Perumalla

[philip schwarz]

>i find the claim that tdd is only good 
>when there are lots of lines of code odd, because to me it is more 
>about state space than about lines of code. 

Interesting, here is how he puts it:

"if your design could create code that was never more than 3 or 4 lines long, and classes that had 7 of these 3 to 5 line methods, why do you need TDD? TDD is absolutely critical and essential when your code is, you know, a couple of 100,000 lines of code, it would be absolutely insane not to use it, but if your codebase is a 100 lines of code, who needs it. So we are doing a whole lot of things that are good practices, but the need for them could be eliminated, if you were thinking about design correctly."

Philip

On Monday, 21 October 2013 19:30:54 UTC+1, raould wrote:

...like: i would expect the rules thing that 'couldn't be done' would
best be tried in a lisp. and i find the claim that tdd is only good
when there are lots of lines of code odd, because to me it is more
about state space than about lines of code.

[philip schwarz]

>i find the claim that tdd is only good when there are lots of lines of code odd

Today Rich Hickey, the designer of the Clojure language, tweeted:

@stuarthalloway

2h

the Agile Manifesto http://agilemanifesto.org/  is easily abused to spread complexity #narcissisticdesign

In replying to him, I referenced Uncle Bob's post, "Simple Hickey" (http://blog.8thlight.com/uncle-bob/2011/10/20/Simple-Hickey.html), and it seems to me that there are some similarities between what Hickey thinks of TDD and what West thinks about it.

See below for the second part of the post:

Here’s another talk from Rich: Hammock Driven Development (http://blip.tv/clojure/hammock-driven-development-4475586), in which he encourages us to think instead of just writing gobs and gobs of code.

So here’s the deal. Rich is concerned, and rightly so, that we have a culture of complexity. That when programmers are given a task, they race ahead and write masses of tangled code, using “easy” frameworks and tools, without giving the problem due thought. That we confuse easiness, with simplicity. (e.g. Rails is easy, it is not simple.) His complaint about tests is that we used them to replace thought. That we feel good about ourselves because we’ve written tests, and yet we haven’t actually given the time to the problem that the problem deserves. We haven’t made the problem simple. We’ve just done what was easy.

Now, truth be told, the Agile community, and the entire software community is infected with this disease. All too often we do what’s easy, at the expense of what’s simple. And so we make a mess. But that is not now, nor was it ever, a value of agile development. And it was certainly not a value of software craftsmanship! Indeed, doing what is simple as opposed to what is easy is one of the defining characteristics of a software craftsman.

In the end, I think Rich’s perception of TDD is skewed by what he sees out in the industry. Frankly, I think he’s missing a bet. I imagine he’d find that the practice was as helpful to him as it has been to me. Not as a way to avoid thinking and rushing towards a mess; but rather as a disciplined way of being thorough, careful, and thoughtful.

Now, ask yourself what TDD means to you. Is TDD a discipline you use to make things easy? Or is it a discipline you use in order to be thoughtful, careful, and to keep things simple?"

[Matteo Vaccari]

On Sun, Oct 27, 2013 at 4:56 PM, philip schwarz <philip.joh...@googlemail.com> wrote:

...

So here’s the deal. Rich is concerned, and rightly so, that we have a culture of complexity. That when programmers are given a task, they race ahead and write masses of tangled code, using “easy” frameworks and tools, without giving the problem due thought. That we confuse easiness, with simplicity. (e.g. Rails is easy, it is not simple.) His complaint about tests is that we used them to replace thought. That we feel good about ourselves because we’ve written tests,

This is a crucial problem.  I too see people writing tests for the feeling of "I write tests, therefore I rock!!" but never stop questioning: am I writing good tests?  Tests give you "permission" to go ahead, you've done the right thing, move on.

The same thing happens, or used to happen, with design patterns.  I used 4 patterns, therefore I rock, no need to think further.

I think we all agree here that Rick Hickey (and David West?) are complaining about TDD done poorly; they probably would not complain about TDD done well.  But they have a point; many people do TDD poorly.  

Doing TDD poorly is not a very big deal, actually.  I mean, doing TDD poorly is still a vast improvement over doing programming without tests poorly.  Doing TDD poorly only becomes a big problem when I think I'm doing it very well... and stop questioning and improving.

The big obstacle I see in getting individuals and teams to do TDD well is the love of complexity, and that is a bigger problem with people who are "good" programmers, or think they are good.  And also with the fact that when you look at the market for programming training, what gets the most press are specific technologies, not fundamental issues that make you think like "Object Thinking" or GOOS or the meaning of "Simple".

What do you think?

Matteo

[philip schwarz]

The other way I responded to Halloway, was as follows

‏@philip_schwarz @stuarthalloway but 10th principle of Agile sw is "Simplicity--the art of maximizing the amount of work not done--is essential."

@philip_schwarz @stuarthalloway but "the design strategy in XP is to always have the simplest design that runs the current test suite" @KentBeck XP Explained  

to which he replied with

@stuarthalloway @philip_schwarz if you accidentally delete 'test' dir, must you then delete 'src' dir to comply with XP design? :-) 

And that reminded me of a very interesting post that Uncle Bob wrote recently: Test First (http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html).

The value that Uncle Bob attaches to the tests resulting from TDD is huge compared to that which seems to be attached to them by West, Hickey and Halloway.

Here are some excerpts from Uncle Bob's post:

"I know this sounds ridiculous; but consider. If somehow all your production code got deleted, but you had a backup of your tests, then you'd be able to recreate the production system with a little work. Indeed, you'd also enjoy the benefit of The Second System Effect. The code would be better because it was the second time you'd've written it. So, in the end, you'd wind up with a fully functional and better designed system.

If, however, it was your tests that got deleted, then you'd have no tests to keep the production code clean. The production code would inevitably rot, slowing you down. The quality of the code, and the productivity of the team would be caught in the downward spiral towards zero -- and there's nothing they could do to stop it other than trying recreate the test suite. And, as we noted, recreating the test suite is very hard indeed.

If we lose the production code, we end up with a better designed system that stays clean because it has tests. If we lose the tests, then the production code rots and the team slows down in a never ending spiral of lost productivity.

So we can conclude that if it became a choice between the tests or the production code, we'd rather preserve the tests. And this means that the tests are a more important component of the system than the production code is. Because the tests are the specs."

...

The bottom line of all this is that we should consider our tests as beingfirst. We already know we should write them first; but we should also clean them first, maintain them first, think of them first, and keep them first. We should give our tests the highest priority.

That is what "Test First" really means. The Tests Come First!"

Philip

[George Dinwiddie]

Matteo,

On 10/27/13 12:33 PM, Matteo Vaccari wrote:
>
>
>
> On Sun, Oct 27, 2013 at 4:56 PM, philip schwarz
> <philip.joh...@googlemail.com

> <mailto:philip.joh...@googlemail.com>> wrote:
>
> ...
> So here’s the deal. Rich is concerned, and rightly so, that we have
> a culture of complexity. That when programmers are given a task,
> they race ahead and write masses of tangled code, using “easy”
> frameworks and tools, without giving the problem due thought. That
> we confuse easiness, with simplicity. (e.g. Rails is easy, it is not
> simple.) His complaint about tests is that we used them to replace
> thought. That we feel good about ourselves because we’ve written tests,
>
>
> This is a crucial problem. I too see people writing tests for the
> feeling of "I write tests, therefore I rock!!" but never stop
> questioning: am I writing good tests? Tests give you "permission" to go
> ahead, you've done the right thing, move on.

I can't imagine that feeling if you're doing TDD. It's not a matter of
having written tests (that's a test-after phenomena IME), or that the
tests are "good tests." It's whether or not the test pushes the design
in a direction that will satisfy the requirements.

To me, that's the heart of TDD.

> The same thing happens, or used to happen, with design patterns. I used
> 4 patterns, therefore I rock, no need to think further.
>
> I think we all agree here that Rick Hickey (and David West?) are
> complaining about TDD done poorly; they probably would not complain
> about TDD done well. But they have a point; many people do TDD poorly.

I'd love to see some examples of TDD done poorly.

> Doing TDD poorly is not a very big deal, actually. I mean, doing TDD
> poorly is still a vast improvement over doing programming without tests
> poorly. Doing TDD poorly only becomes a big problem when I think I'm
> doing it very well... and stop questioning and improving.
>
> The big obstacle I see in getting individuals and teams to do TDD well
> is the love of complexity, and that is a bigger problem with people who
> are "good" programmers, or think they are good. And also with the fact
> that when you look at the market for programming training, what gets the
> most press are specific technologies, not fundamental issues that make
> you think like "Object Thinking" or GOOS or the meaning of "Simple".
>
> What do you think?
>
> Matteo

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Matteo Vaccari]

This is a crucial problem.  I too see people writing tests for the
feeling of "I write tests, therefore I rock!!" but never stop
questioning: am I writing good tests?  Tests give you "permission" to go
ahead, you've done the right thing, move on.

I can't imagine that feeling if you're doing TDD. It's not a matter of having written tests (that's a test-after phenomena IME), or that the tests are "good tests." It's whether or not the test pushes the design in a direction that will satisfy the requirements.

To me, that's the heart of TDD.

Of course! But there is a risk of getting lost in the tests, so to speak.  Getting bogged down in "how do I prove that my code gets called from the rest of the system" (for instance) when I still have to write the interesting things that my code should do.

 

The same thing happens, or used to happen, with design patterns.  I used
4 patterns, therefore I rock, no need to think further.

I think we all agree here that Rick Hickey (and David West?) are
complaining about TDD done poorly; they probably would not complain
about TDD done well.  But they have a point; many people do TDD poorly.

I'd love to see some examples of TDD done poorly.

My friend Uberto Barbini, who is also on this list, is going to show some at the Italian Agile Day next November.

Apart from that, here is one example from my experience:

http://matteo.vaccari.name/blog/archives/593

Matteo

 

[George Dinwiddie]

Matteo,

Ah, what the rails community thinks is TDD differs from mine. I would
not try to use GUI tests to drive the whole system. I also would not
couple the GUI to the DB schema (as I see many do in Rails apps).

Thanks for the insights. I like your suggested approach much better, for
quite a number of reasons.

Another alternative would be to have the AdminTable object be the model
for the table on the page, but do the looping through the rows &
converting to HTML in the template. This allows testing that the model
is created properly. One GUI test can verify that the template produces
the correct display for a given AdminTable. This keeps the HTML
generation in the view.

Many years ago, Alex Chaffee told me "The model calculates; the view
iterates." I've found that to be a good heuristic.

[Manuel Paccagnella]

Il giorno domenica 27 ottobre 2013 17:33:40 UTC+1, Matteo Vaccari ha scritto:

Doing TDD poorly is not a very big deal, actually.  I mean, doing TDD poorly is still a vast improvement over doing programming without tests poorly.  Doing TDD poorly only becomes a big problem when I think I'm doing it very well... and stop questioning and improving.

FWIW, I think that doing TDD poorly can be a big deal if done so it produces brittle, uncomprehensible and unmaintainable tests. That could very well be the death of TDD in that company if you are trying to introduce it.

Having said that, I'm "test infected" but I've recently started to rethinking about the role of TDD in different contexts. In the average Java or Ruby project it's an extremely useful practice to employ (especially on a design perspective), but there are other factors to consider. I appreciate and enjoy the posts of Uncle Bob, they resonate with my understanding and point of view, but in a context like the one depicted by David West maybe he has a point. I hope that one day I'll publish the post I'm writing on this subject.

[Uberto Barbini]

>>> I think we all agree here that Rick Hickey (and David West?) are
>>> complaining about TDD done poorly; they probably would not complain
>>> about TDD done well. But they have a point; many people do TDD poorly.
>>
>>
>> I'd love to see some examples of TDD done poorly.
>>
>
> My friend Uberto Barbini, who is also on this list, is going to show some at
> the Italian Agile Day next November.

yep, also this Friday at London Agile Tour.
The title of the talk is When TDD Goes Awry and it started as
reflection with Matteo about these same lines.

As Nat (re)pointed out recently on this list, TDD is a design
technique, not a way to test the application.
Interestingly enough if you try only to test the application (because
you know, I'm an architect and I know how to design) you'll finish
with a lot of very poor regression tests and no design at all.

Uberto

[Torbjörn Kalin]

On Sun, Oct 27, 2013 at 5:33 PM, Matteo Vaccari <vac...@pobox.com> wrote:

I think we all agree here that Rick Hickey (and David West?) are complaining about TDD done poorly; they probably would not complain about TDD done well.  But they have a point; many people do TDD poorly.  

As we all know, there's a difference between TDD and (non-TDD) test-first. However, sometimes I feel we forget about that in these discussions. More often, I think people with (negative) opinions about TDD tend to mix the two.

Also, I believe most people who claim they do TDD actually do test-first (hands up if you always do triangulation (ok, I agree it's a gray scale :)). Doing test-first doesn't mean you'll end up with something bad. On the contrary, the tests will hopefully support you in your refactorings. However, if you do test-first with a bad design, your tests will probably hinder you more than help you.

Perhaps that's what Hickey and West try to communicate?

Also, I believe it's quite easy to do test-first poorly, but really hard to do TDD poorly. If you do TDD poorly you will automatically start doing (non-TDD) test-first.

/T

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

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

[Manuel Paccagnella]

Il giorno lunedì 28 ottobre 2013 21:07:00 UTC+1, Torbjörn Kalin ha scritto:

Also, I believe it's quite easy to do test-first poorly, but really hard to do TDD poorly. If you do TDD poorly you will automatically start doing (non-TDD) test-first.

At this point I have to ask: what’s the difference between test-first and TDD for you? I think that TFD was the original name that Kent Beck changed to TDD when he was writing his book “Test Driven Development: By Example”. But there are a lot of definitions out there. Someone thinks that TDD like TFD but when the architecture is not already clear, others see TDD as TFD + refactoring (?!).

My point is that sadly we don’t have many precise definitions. And this is crucial to be on the same page and have a meaningful debate.

Well, maybe there is an agreed upon definition of TDD here (sorry, I’m new in this group) :)

[Angel Java Lopez]

Umm.. a bit long thread, maybe I missed some email....

But, any concrete written example of "to do TDD poorly"? English is not my language, and I cannot grasp all the video talks.

My guess point: following simple rules, you cannot do TDD poorly. If you "do poorly", then it is not TDD (you started to break YAGNI, don't write minimal code, skipped refactor, etc)

Angel "Java" Lopez

@ajlopez

--

[Donaldson, John]

I think TDD can (and should) be about design.

But what am I doing at the moment, retrofitting tests onto a legacy application?

Trying to capture the essence of the design so that I don’t break it as I start to modify it.

Design-driven testing?!

 

John D.

--

[Björn Rasmusson]

Angel Java Lopez wrote:

Umm.. a bit long thread, maybe I missed some email....

But, any concrete written example of "to do TDD poorly"? English is not my language, and I cannot grasp all the video talks.

My guess point: following simple rules, you cannot do TDD poorly. If you "do poorly", then it is not TDD (you started to break YAGNI, don't write minimal code, skipped refactor, etc)

Angel "Java" Lopez

@ajlopez

On Mon, Oct 28, 2013 at 8:44 PM, Manuel Paccagnella <manuel.pa...@gmail.com> wrote:

Il giorno lunedì 28 ottobre 2013 21:07:00 UTC+1, Torbjörn Kalin ha scritto:

Also, I believe it's quite easy to do test-first poorly, but really hard to do TDD poorly. If you do TDD poorly you will automatically start doing (non-TDD) test-first.

At this point I have to ask: what’s the difference between test-first and TDD for you? I think that TFD was the original name that Kent Beck changed to TDD when he was writing his book “Test Driven Development: By Example”. But there are a lot of definitions out there. Someone thinks that TDD like TFD but when the architecture is not already clear, others see TDD as TFD + refactoring (?!).

My point is that sadly we don’t have many precise definitions. And this is crucial to be on the same page and have a meaningful debate.

Well, maybe there is an agreed upon definition of TDD here (sorry, I’m new in this group) :)

Keith Braithwaite describes one anti-pattern in his workshop "TDD as if You Meant It" as (basically a copy of his slide):
"
TDD the way it's often done ...

I see a lot of this thing:
- Think up a design
- Write a bunch of test that say the design exist
- Write the implementation
- Test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug ...
- Write TODO saying to refactor
"

Its definitely an anti-pattern, but is it this some people refers to as (non-TDD) test-first?

Best regards
Björn

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

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

[Manuel Paccagnella]

Il giorno martedì 29 ottobre 2013 11:14:36 UTC+1, Björn Rasmusson ha scritto:

Keith Braithwaite describes one anti-pattern in his workshop "TDD as if You Meant It" as (basically a copy of his slide):
"
TDD the way it's often done ...

I see a lot of this thing:
- Think up a design
- Write a bunch of test that say the design exist
- Write the implementation
- Test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug, test, debug ...
- Write TODO saying to refactor
"

Uncle Bob defines TDD with 3 laws:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

This set of rules effectively locks you in a virtuous circle of very short feedback loops, in which basically all relevant production code is tested and the overall design is informed and guided by tests. More than that, they prevents a bunch of common mistakes:

• You can’t write a bunch of tests and then go implement a big chunk of production code.
• You can’t write a test and then write and entire subsystem.
• You can’t write tests after the fact.

Its definitely an anti-pattern, but is it this some people refers to as (non-TDD) test-first?

Yes, but as far as I know there isn’t a single, precise and shared definition on what TDD exactly is. Maybe the best thing is looking for that definition at the source.

Cheers,

Manuel

[Torbjörn Kalin]

In my vocabulary, TDD is the strict practise where you are not allowed to add any production code unless a test tells you to (with baby steps and YAGNI). The more general term test-first means that you write a test before the code, but without the strictness.

Test-first could give you a result similar to test-last except that the design is guaranteed to be testable.

But it seems I need to update my volcabulary...

Point is, I don't think I've ever met anyone claiming to practise TDD who actually does (strictly speaking). They all do test-first. Which is related to your point.

/T

[Kevin Rutherford]

Hi,
What I'm about to say is probably heresy...

I don't believe it's possible to write an automated unit test without
having done some design in my head first. (There, said it!)

I want to write a test, so there must be observable consequences of
some action. I must have an idea what consequences I want (given the
context of my ongoing development). And so I must posit the existence
of an object whose responsibility is to effect those consequences, and
the existence of a message that stimulates that object into executing
that responsibility. So I'm placing an object (new or existing) into a
context (new or existing) that I have designed. No? That's design,
even if it took less than a second.

And when I begin typing the test, I have to decide how the
consequences will be made discoverable by that test. I could assert on
state change(s) within an object, or I could assert on whether certain
messages were sent. That's a design decision, and it radically affects
the "tone" (coupling, architecture, etc) of all subsequent code in
this area.

Sure, the /internals/ of the object-under-test can be "discovered" now
that the test exists to frame them, but the /externals/ of the object
are (in my practice, so far as I can observe it) contextual design
decisions that I have to make without the "aid" of the test.

Someone please tell me where I'm going wrong?
Cheers,
Kevin
--
http://xpsurgery.com -- remote one-to-one tutoring in TDD and OO
http://kevinrutherford.co.uk -- software development coaching
http://refactoringinruby.info -- Refactoring in Ruby, the book

[Angel Java Lopez]

I usually design at breakfast ;-), but trying only external behavior.

Like

lexer.nextToken() returning { value: ... , type: ... }

then write tests like

var lexer = mymodule.createLexer("name");

var token = lexer.nextToken();

assert.ok(token);

assert.equals(token.value, "name");

assert.equals(token.type, TokenType.Name);

but the internal state, behavior, is not in the breakfast design (or it could be, but not carved in stone, only suggestions)

And so on....

Angel "Java" Lopez

@ajlopez

[Kevin Rutherford]

Hi Angel,

On Tue, Oct 29, 2013 at 2:58 PM, Angel Java Lopez <ajlop...@gmail.com> wrote:
> I usually design at breakfast ;-), but trying only external behavior.

Breakfast is a great time to do design :)

Maybe I'm using the word "design" oddly: To me, design is the messages
between the objects. The objects themselves, and their internal code,
are all implementation choices. TDD helps me when those implementation
choices are difficult, but it feels like the tests are always written
in the context of having already done the design -- ie. the messages
between the objects are already visualised, at least to some extent.

[J. B. Rainsberger]

On Sun, Oct 27, 2013 at 9:32 PM, George Dinwiddie <li...@idiacomputing.com> wrote:

 

This is a crucial problem.  I too see people writing tests for the
feeling of "I write tests, therefore I rock!!" but never stop
questioning: am I writing good tests?  Tests give you "permission" to go
ahead, you've done the right thing, move on.

I can't imagine that feeling if you're doing TDD. It's not a matter of having written tests (that's a test-after phenomena IME), or that the tests are "good tests." It's whether or not the test pushes the design in a direction that will satisfy the requirements.

To me, that's the heart of TDD.

I absolutely felt like this when I first started. Look at me! I write tests! You all suck because you don't write tests! I didn't know any better; I figured that I was doing better than those around me.

With nobody to challenge this self-image, I could have easily gone no further. Fortunately, I needed help learning how to practise TDD, which led to finding a lot of you people, who challenged my self-image, encouraged (sometimes forced) me to grow, and all that good stuff.

All this is to say that no practice guaranteed mindfulness, which can account for how people feel the way that Matteo described.

I think we all agree here that Rick Hickey (and David West?) are
complaining about TDD done poorly; they probably would not complain
about TDD done well.  But they have a point; many people do TDD poorly.

I'd love to see some examples of TDD done poorly.

Easy: don't refactor. No fair invoking the "No True Scotsman" argument. :)

 

The big obstacle I see in getting individuals and teams to do TDD well
is the love of complexity, and that is a bigger problem with people who
are "good" programmers, or think they are good.  And also with the fact
that when you look at the market for programming training, what gets the
most press are specific technologies, not fundamental issues that make
you think like "Object Thinking" or GOOS or the meaning of "Simple".

What do you think?

Many programmers feel bored working on enterprise solutions to boring business problems. I encourage these programmers to see TDD as *the* intellectual challenge. How do I choose good tests? How do I make them tiny? How do I choose the sequence to write them? What unnecessary code can I remove? Which test do I need to write which will force me to write the production code that I think I need to write?

These questions can keep a programmer busy.

-- 

J. B. (Joe) Rainsberger :: http://www.agiletutor.com :: http://www.jbrains.ca ::

[J. B. Rainsberger]

On Mon, Oct 28, 2013 at 9:07 PM, Torbjörn Kalin <tgo...@kalin-urena.com> wrote:

 

Also, I believe it's quite easy to do test-first poorly, but really hard to do TDD poorly. If you do TDD poorly you will automatically start doing (non-TDD) test-first.

I see it the other way: if a programmer designs the way e wants, then implements the design test-first, e will more likely perform the steps of test-first programming correctly and diligently compared to forcing emself to practise TDD diligently and defer design decisions. Test-first has fewer rules to follow.

-- 

[J. B. Rainsberger]

On Tue, Oct 29, 2013 at 2:32 PM, Kevin Rutherford <ke...@rutherford-software.com> wrote:

 

What I'm about to say is probably heresy...

I don't believe it's possible to write an automated unit test without
having done some design in my head first.  (There, said it!)

Not heresy. Reality. We simply don't commit to that insane design in our head. Not controversial in the slightest. :)

[Torbjörn Kalin]

On Tue, Oct 29, 2013 at 6:55 PM, J. B. Rainsberger <m...@jbrains.ca> wrote:

On Mon, Oct 28, 2013 at 9:07 PM, Torbjörn Kalin <tgo...@kalin-urena.com> wrote:

 

Also, I believe it's quite easy to do test-first poorly, but really hard to do TDD poorly. If you do TDD poorly you will automatically start doing (non-TDD) test-first.

I see it the other way: if a programmer designs the way e wants, then implements the design test-first, e will more likely perform the steps of test-first programming correctly and diligently compared to forcing emself to practise TDD diligently and defer design decisions. Test-first has fewer rules to follow.

I agree. In this case the difficulty is not in doing test-first, but in creating a good design.

/T

[Mike Stockdale]

In TDD, writing a test *is* a design activity.  We design a little piece of expected behavior and the API that will expose that behavior.  We document the design with a test.  Then, we design the implementation that makes that test pass.  So we are constantly designing.  When TDD goes wrong is when people stop designing and treat it like a mindless rote exercise.

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Cheers,
Mike Stockdale

fitSharp
Syterra Software Inc.

[Ben Biddington]

So you have to _listen_, right?

I have test-driven plenty of programs that sucked because I ignored the pain the tests were inflicting upon me.

[J. B. Rainsberger]

On Tue, Oct 29, 2013 at 10:04 PM, Mike Stockdale <jedi...@syterra.com> wrote:

 

In TDD, writing a test *is* a design activity.  We design a little piece of expected behavior and the API that will expose that behavior.  We document the design with a test.  Then, we design the implementation that makes that test pass.  So we are constantly designing.  When TDD goes wrong is when people stop designing and treat it like a mindless rote exercise.

Yes, although I'm a little unsure about the connexion to what I wrote.

-- 

[J. B. Rainsberger]

On Tue, Oct 29, 2013 at 10:26 PM, Ben Biddington <ben.bid...@gmail.com> wrote:

I have test-driven plenty of programs that sucked because I ignored the pain the tests were inflicting upon me.

If you ignored the pain the tests were inflicting upon you, then were you really test-*driving*? ;) I'm sure you were test-*first*ing.

-- 

[Anthony Green]

Kevin Rutherford wrote:
> Maybe I'm using the word "design" oddly: To me, design is the messages
> between the objects.

The protocols that GOOS refers to ?

> The objects themselves, and their internal code,
> are all implementation choices. TDD helps me when those implementation
> choices are difficult, but it feels like the tests are always written
> in the context of having already done the design -- ie. the messages
> between the objects are already visualised, at least to some extent.

I get the sense each object plays a role: a peer, a collaborator, a
value object, maybe even more than one, so designing is like a writing
workshop we know the rough narrative of our drama and through design
explore and flesh out the dialogue between the actors that move the
story forward.
For some scenes we get need all the actors onstage, for others where
getting the real actors would be expensive we use stand ins to take part
in the exchange, and read the dialogue from the rough improvised script.
There are props and other plot devices actors make use of. Then there's
continuity to check. As we feel parts of the script comes together we
make less changes to it and it becomes hardened. We continue to edit, to
drop scenes and add others and we get more of a feeling for how our
drama is playing out.

I joked with Matt Wynne my term for this was 'Object Theatre'.

I get that with a single narrative strand this is probably more akin to
Java's main() rather than Smalltalk's object pool. Maybe for proper OO I
should be looking to employ The Mythology Engine.

[Nat Pryce]

What a great metaphor. Is that an explanation you use at the BBC?

www.natpryce.com

[Kevin Rutherford]

On Sat, Nov 2, 2013 at 6:08 AM, Anthony Green
<anthony.ch...@gmail.com> wrote:
>
> I get the sense each object plays a role: a peer, a collaborator, a value
> object, maybe even more than one, so designing is like a writing workshop we
> know the rough narrative of our drama and through design explore and flesh
> out the dialogue between the actors that move the story forward.
> For some scenes we get need all the actors onstage, for others where getting
> the real actors would be expensive we use stand ins to take part in the
> exchange, and read the dialogue from the rough improvised script. There are
> props and other plot devices actors make use of. Then there's continuity to
> check. As we feel parts of the script comes together we make less changes to
> it and it becomes hardened. We continue to edit, to drop scenes and add
> others and we get more of a feeling for how our drama is playing out.

Great description! CRC, anyone?

> I joked with Matt Wynne my term for this was 'Object Theatre'.

Very nice. Think I'll start using that...

[J. B. Rainsberger]

On Sat, Nov 2, 2013 at 7:08 AM, Anthony Green <anthony.ch...@gmail.com> wrote:

I get the sense each object plays a role: a peer, a collaborator, a value object, maybe even more than one, so designing is like a writing workshop we know the rough narrative of our drama and through design explore and flesh out the dialogue between the actors that move the story forward.
For some scenes we get need all the actors onstage, for others where getting the real actors would be expensive we use stand ins to take part in the exchange, and read the dialogue from the rough improvised script. There are props and other plot devices actors make use of. Then there's continuity to check. As we feel parts of the script comes together we make less changes to it and it becomes hardened. We continue to edit, to drop scenes and add others and we get more of a feeling for how our drama is playing out.

Very nice. Expands on the "stunt double" metaphor that explains the term "test double".

-- 

[Steve Tooke]

On 2 November 2013 06:08, Anthony Green <anthony.ch...@gmail.com> wrote:

For some scenes we get need all the actors onstage, for others where getting the real actors would be expensive we use stand ins to take part in the exchange, and read the dialogue from the rough improvised script. There are props and other plot devices actors make use of. Then there's continuity to check. As we feel parts of the script comes together we make less changes to it and it becomes hardened. We continue to edit, to drop scenes and add others and we get more of a feeling for how our drama is playing out.

I joked with Matt Wynne my term for this was 'Object Theatre'.

That's a great metaphor, thanks I really enjoyed it. 

 

I get that with a single narrative strand this is probably more akin to Java's main() rather than Smalltalk's object pool. Maybe for proper OO I should be looking to employ The Mythology Engine.

Perhaps it's more like Java's main if you think you can lay out the whole narrative for your actors. Smalltalk's object pool could be more like an improv performance. Our tests are just the rehearsal, some constraints we set for the actors, but once the app is up and running they need to deal with whatever the audience throws at them.

Steve

--

Steve Tooke :: heavi.es

+44 7919 337 463 :: +44 20 8133 4134

skype:stevetooke :: twitter.com/tooky

Heavies Limited

Registered Number: 7612561

Registered Address: Parmenter House, 57 Tower Street, Winchester SO23 8TD

[J. B. Rainsberger]

On Sat, Nov 2, 2013 at 11:00 AM, Steve Tooke <st...@heavi.es> wrote:

 

Perhaps it's more like Java's main if you think you can lay out the whole narrative for your actors. Smalltalk's object pool could be more like an improv performance. Our tests are just the rehearsal, some constraints we set for the actors, but once the app is up and running they need to deal with whatever the audience throws at them.

I have a hard time seeing the Smalltalk object pool as anything other than the radio: a band of frequencies, each broadcasting its own story. With luck, "stations" don't interfere with one another, but they're always on. A Java main() is a single station. An application server or Smalltalk image is a radio band.

-- 

[philip schwarz]

>TDD is absolutely critical and essential when your code is, you know, a couple of 100,000 lines of code

Codebases - Millions of lines of code: http://www.informationisbeautiful.net/visualizations/million-lines-of-code/

May be useful to help understand the kinds and number of systems where TDD is "absolutely critical and essential", e.g. Quake 3 Engine and larger.

Philip

On Sunday, 27 October 2013 15:22:27 UTC, philip schwarz wrote:

>i find the claim that tdd is only good 
>when there are lots of lines of code odd, because to me it is more 
>about state space than about lines of code. 

Interesting, here is how he puts it:

"if your design could create code that was never more than 3 or 4 lines long, and classes that had 7 of these 3 to 5 line methods, why do you need TDD? TDD is absolutely critical and essential when your code is, you know, a couple of 100,000 lines of code, it would be absolutely insane not to use it, but if your codebase is a 100 lines of code, who needs it. So we are doing a whole lot of things that are good practices, but the need for them could be eliminated, if you were thinking about design correctly."

Philip

On Monday, 21 October 2013 19:30:54 UTC+1, raould wrote:

...like: i would expect the rules thing that 'couldn't be done' would
best be tried in a lisp. and i find the claim that tdd is only good
when there are lots of lines of code odd, because to me it is more
about state space than about lines of code.

[philip schwarz]

West's viewpoint on TDD reminds me of the following extract from an interview with Donald Knuth (http://www.informit.com/articles/article.aspx?p=1193856):

Q: today’s developers frequently build programs writing small code increments followed by immediate compilation and the creation and running of unit tests. What are your thoughts on this approach to software development?

A: ...the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up."

[philip schwarz]

>I think we all agree here that Rick Hickey (and David West?) are complaining about TDD done poorly; they probably would not complain about TDD done well.  But they have a point; many people do TDD poorly. 

To see what Hickey thinks about testing, here is what he said at 43':20'' of Bay Area Clojure Meetup, 6/3/09: Rich Hickey presents Clojure (http://blip.tv/tom-faulhaber/bay-area-clojure-meetup-6-3-09-rich-hickey-presents-clojure-s-chunks-answers-general-questions-2318585):

There is definitely value to tests, but there is definitely cost to tests if you spend your time writing them, so let's say, you spend half your time writing tests, and half your time writing code, and that gives you X bugs, and let's say I spend half of my time thinking about my problem, and the other half writing code, and that gives me X over 2 bugs, half as many bugs, what's better: to tests or no?  For me it is no.

I also think there is a culture about testing that's coming up around these OO languages and all their mutability, basically well I have this huge program and I know potentially if I change something over here, something way over there is going to fall over so I've got to run 40,000 tests every time I change a line of code...that's absolutely intrinsic in the need of the application,

it is not a fundamental property of the value of testing, ... so Clojure is not that way, Clojure is functional, I don't have those kinds of problems...if it is broken I am going to find out in no time, and I'd rather spend half of my time thinking about what I am doing, it is definitely better for me, I write better ...Clojure is not bug free, but it is not bad, considering it has no tests, but it is a tradeoffs thing...I think I would hate my life if I had to do the kind of test writing people advocate, I wouldn't be a programmer, I love thinking about these problems, trying to get it right in my head before I sit down and type away,and it has yielded decent programs, so that is my recipe, I am not saying it should be everybody's, AND I do see the value of having a test suite to make sure you don't have a regression, and so I am thrilled to see ... and I am happy to run it, it is not like I am saying testing is bad...I tried it believe me. 

Philip

On Sunday, 27 October 2013 16:33:40 UTC, Matteo Vaccari wrote:

On Sun, Oct 27, 2013 at 4:56 PM, philip schwarz <philip.joh...@googlemail.com> wrote:

...

So here’s the deal. Rich is concerned, and rightly so, that we have a culture of complexity. That when programmers are given a task, they race ahead and write masses of tangled code, using “easy” frameworks and tools, without giving the problem due thought. That we confuse easiness, with simplicity. (e.g. Rails is easy, it is not simple.) His complaint about tests is that we used them to replace thought. That we feel good about ourselves because we’ve written tests,

This is a crucial problem.  I too see people writing tests for the feeling of "I write tests, therefore I rock!!" but never stop questioning: am I writing good tests?  Tests give you "permission" to go ahead, you've done the right thing, move on.

The same thing happens, or used to happen, with design patterns.  I used 4 patterns, therefore I rock, no need to think further.

I think we all agree here that Rick Hickey (and David West?) are complaining about TDD done poorly; they probably would not complain about TDD done well.  But they have a point; many people do TDD poorly.  

Doing TDD poorly is not a very big deal, actually.  I mean, doing TDD poorly is still a vast improvement over doing programming without tests poorly.  Doing TDD poorly only becomes a big problem when I think I'm doing it very well... and stop questioning and improving.

The big obstacle I see in getting individuals and teams to do TDD well is the love of complexity, and that is a bigger problem with people who are "good" programmers, or think they are good.  And also with the fact that when you look at the market for programming training, what gets the most press are specific technologies, not fundamental issues that make you think like "Object Thinking" or GOOS or the meaning of "Simple".

What do you think?

Matteo

[philip schwarz]

Hickey on TDD (in interview http://www.codequarterly.com/2011/rich-hickey/ ):

Fogus: You have been known to speak out against test-driven development. Do you mind elaborating on your position?

Hickey: I never spoke out ‘against’ TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design.

[philip schwarz]

Brian Marick, Agile Manifesto signatory, creator of Midje (the Clojure test framework) and author of 'Functional Programming for the Object-Oriented Programmer' (https://leanpub.com/fp-oo) fell out with Hickey over TDD.

Here is Marick in http://www.exampler.com/blog/2011/09/30/a-postscript-about-the-validity-of-claims/:

The problem with talking about the tone of the Clojure community is that almost no statement can ever be proven. Rich Hickey and I went around and around about this on Twitter. So after citing this statement of his:

If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem.

… I could say that I read a snarky “[those losers]” implicitly attached to “okay for them.” I could say that “fifty percent of your time writing tests” and “rather spend that time thinking about my problem” are complete mischaracterizations of TDD as it’s actually done. And I can say that those mischaracterizations and that snark will be aped by programmers who want to be Rich Hickey.

I could say all those things, but the statement as written isn’t false. It can even be given a generous reading. But—if I’m right—programmers like me won’t stick around to hear defensible statements defended. They’ll just look for friendlier places where they aren’t expected to deal with decade-old arguments as if they were new and insightful.

Please note that I’m not saying Rich Hickie’s design approach is wrong. I suspect for the kinds of problems he solves, it may even be true that his approach is better across all designers than TDD is.

Philip

[philip schwarz]

Stuart Sierra (author of Practical Clojure) to Brian Marick on Rich Hickey's view of TDD:

...Clojure was designed to be “a tool for hardcore people to solve hardcore problems.” That’s what Rich Hickey wanted, and that’s what he built. He’s a hardcore person, and like many such people, he isn’t shy about expressing his opinions. Don’t take it personally. (And don’t try to hold a cogent dialogue on Twitter ;)

Yes, Rich Hickey doesn’t like TDD. I’m kind of meh on it, and I’ve written two Clojure testing frameworks! But it’s not a moral judgment. We’re not trying to drive anyone away. If anything, we’re trying to find our way to the next evolutionary step on that path. Maybe clojure.test.generative is that step, maybe it isn’t.

I sincerely hope that Clojure can continue to be valuable to both hardcore and “softcore” users. I believe it’s possible. ...

[philip schwarz]

Uberto just tweeted the URL for his slides: http://www.slideshare.net/ubertobarbini/when-tdd-goes-awry

Philip

On Monday, 28 October 2013 18:47:47 UTC, Uberto Barbini wrote:

>>> I think we all agree here that Rick Hickey (and David West?) are
>>> complaining about TDD done poorly; they probably would not complain
>>> about TDD done well.  But they have a point; many people do TDD poorly.
>>
>>

>> I'd love to see some examples of TDD done poorly.
>>
>

> My friend Uberto Barbini, who is also on this list, is going to show some at
> the Italian Agile Day next November.

yep, also this Friday at London Agile Tour.
The title of the talk is When TDD Goes Awry and it started as
reflection with Matteo about these same lines.

As Nat (re)pointed out recently on this list, TDD is a design
technique, not a way to test the application.
Interestingly enough if you try only to test the application (because
you know, I'm an architect and I know how to design) you'll finish
with a lot of very poor regression tests and no design at all.

Uberto

[philip schwarz]

Hey Uberto,

on slide 18 you lay down some Mocking rules. The first one is "At most one mock and many stubs". The second one is "Use stubs for internals and close friends, mocks for collaborators (i.e. listeners)".

Firstly, if you are at all able to elaborate on these I would appreciate it.

Secondly, in the first edition of "The Art of Unit Testing", Roy Hosherove has the following guideline:

"In a test where you test only one thing (which is how I recommend you 
write tests), there should be no more than one mock object. All other 
fake objects will act as stubs. Having more than one mock per test 
usually means you are testing more than one thing, and this can lead 
to complicated or brittle tests 
...Combining stubs and mocks in the same test is a powerful technique, 
but you must take care to have no more than one mock in each test. The 
rest of the fake objects should be stubs that can't break your test. 
Following this practice can lead to more maintainable tests that break 
less often when internal code changes." 

A couple of years ago I mentioned this guideline (in this thread https://groups.google.com/forum/#!searchin/growing-object-oriented-software/osherove/growing-object-oriented-software/wR7h5PqFqco/JpT_tG1jGSwJ ) because I was interested in whether GOOS was aligned with it. Here is what Nat's said:

"So we suggest allowing queries, but expecting commands.

But we don't recommend limiting your tests to just one expectation and
everything else being allowed, and definitely not to just one mock and
the rest being stub objects.

Instead, expect the significant outgoing command messages that you are
testing for -- there may be more than one.  Allow outgoing queries,
the results of which affect the behaviour under test.  Don't constrain
order explicitly unless it is the behaviour being tested, and even
then do so as loosely as possible -- prefer state machines to
sequences, for example.  And ignore any interactions that are not
germane to the behaviour being tested if you cannot avoid them
happening in some other way (in jMock you can use the ignoring clause
to ignore messages or entire objects).

Obviously there are situations where this does not hold.  For example,
if testing a read-through cache, then you would care about the number
of times a query was made to pull data into the cache, so allowing the
query would not actually test the behaviour you want to test.  But
most often, in my experience, it doesn't matter to the functionality of an object how many times a query is performed."

Recently you said that all in all you liked Osherove's book. Was Osherove's guideline partly the inspiration for your two Mock rules above?

[philip schwarz]

>TDD in it's essence is just that - a technique that minimize the unconscious mistake we are going to make while programming.

>I have the feeling that David West overestimate our ability to think flawlessly which in reality is quite the opposite.

In his afterword to Kent Beck's 'Test Driven Development by Example', Martin Fowler explores the idea that the switching done in TDD increases focus, lowers stress, and reduces monotony. Here is the gist of Fowler's idea (I have turned excerpts of his afterword into bullet points): 

1. Programming is hard. 

2. It sometimes feels like trying to keep several balls in the air at 

once: any lapse of concentration and everything comes tumbling down. 

3. TDD helps reduce this feeling, and results in rapid unhurriedness 

(really fast progress despite feeling unhurried). This is because 

working in a TDD development style gives you the sense of keeping just 

one ball in the air at once, so you can concentrate on that ball 

properly and do a really good job with it. 

4. When you are trying to add some new functionality, you are not 

worried about what really makes a good design for this piece of 

function, you are just trying to get a test to pass as easily as 

possible. 

5. When you switch to refactoring mode, you are not worried about 

adding some new function, you are just worried about getting the right 

design. 

6. With both of these activities, you are just focused on one thing at 

a time, and as a result you can concentrate better on that one thing. 

7. Adding features test-first and refactoring, are two monological 

flavours of programming. 

8. A large part of making activities systematic is identifying core 

tasks and allowing us to concentrate on only one at a time. 

9. An assembly line is a mind-numbing example of this - mind numbing 

because you always do the one thing. 

10. Perhaps what test-driven development suggests is a way of breaking 

apart the act of programming into elemental modes, but avoiding the 

monotony by switching rapidly between those modes. 

11. The combination of monological modes and switching gives you the 

benefits of focus and lowers the stress on the brain without the 

monotony of the assembly line.    

Philip

On Tuesday, 22 October 2013 18:36:34 UTC+1, Evgeni Dzhelyov wrote:

Is that Steve who asked the question about the complexity moved to the collaboration of the objects ?

I don't really like West's answer, it's too vague. In my opinion the complexity in the real world is not as comprehensible as he described it. Even in his own example, with all these strange rules you have to apply to the formatting of a document, it will be difficult to be sure the system works as expected in all cases.

I think you need an automated way to verify the behavior of the system just to be sure it is working as expected and you need that for every system of significant importance. What I really like in Kent Beck's ideas is that he acknowledges the fact that people make mistakes and need to find a way to minimize those mistakes. TDD in it's essence is just that - a technique that minimize the unconscious mistake we are going to make while programming. I have the feeling that David West overestimate our ability to think flawlessly which in reality is quite the opposite.

I think the question about the complexity being moved from the code to the collaboration of the objects is a valid and important one.

In a procedural program you can read the code and see the connections there, while in the OO one you need to understand the current objects graph structure. How you deal with that complexity and delegation ? I don't know of any other way than having automated test  ...

A side question: What he describes as behavior oriented design, is that the opposite of what Rich Hickey says about concentrating your model around the data structures ? Are these ideas completely different or I'm missing something ?

On Tue, Oct 22, 2013 at 7:41 PM, J. B. Rainsberger <m...@jbrains.ca> wrote:

On Tue, Oct 22, 2013 at 1:32 PM, Alastair Smith <alas...@alastairsmith.me.uk> wrote:

 

> I think the distinction he's making is that it takes effort to program the same way when programming in Java.  The grain of the language is, at first, entirely procedural.  You have to expend effort to organise the system into collaborating objects.  In Smalltalk, the grain of the language is the other way: you have to expend effort to organise a program in the procedural style he describes.

Is that the case? The code examples that David West displayed near the beginning included "Smalltalk from a Pascal programmer", which suggests to me that it's just as easy to program procedurally in Smalltalk as it is Java, C#, etc. IMHO the problem is more one of adopting the right mindset - thinking in terms of behaviours and messages, rather than flow of execution - and that will cut across all languages. 

I don't find the grain particularly strong in either direction, but if you could have asked me 15 years ago, I'd probably respond differently. For me, TDD made all the difference, and not Java v. Smalltalk.

-- 

J. B. (Joe) Rainsberger :: http://www.myagiletutor.com :: http://www.jbrains.ca ::

http://blog.thecodewhisperer.com
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com

--

 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

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

[George Dinwiddie]

Philip,

On 11/2/13 11:44 AM, philip schwarz wrote:
> Hickey on TDD (in interview
> http://www.codequarterly.com/2011/rich-hickey/ ):
>
>
> Fogus: You have been known to speak out against test-driven development.
> Do you mind elaborating on your position?
>
>
> Hickey:I never spoke out ‘against’ TDD. What I have said is, life is
> short and there are only a finite number of hours in a day. So, we have
> to make choices about how we spend our time. If we spend it writing
> tests, that is time we are not spending doing something else. Each of us
> needs to assess how best to spend our time in order to maximize our
> results, both in quantity and quality. If people think that spending
> fifty percent of their time writing tests maximizes their results—okay
> for them. I’m sure that’s not true for me—I’d rather spend that time
> thinking about my problem. I’m certain that, for me, this produces
> better solutions, with fewer defects, than any other use of my time. A
> bad design with a complete test suite is still a bad design.

I disagree that "If we spend it writing tests, that is time we are not
spending doing something else." To me, writing tests is a means to
thinking about my problem.

To me, this is the crux of the problem with most criticisms of TDD. They
assume that TDD prevents you from doing other worthwhile things. My
experience is that TDD help me do them better.

When you dissolve alcohol in water, the resulting volume is less than
the sum of the two original volumes. TDD is like that. It's not an
addition to the amount of time I would otherwise spend programming.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[philip schwarz]

Yes, I think he is talking about the fourth presupposition of object thinking.

In Chapter 3 of Object Thinking, 'From Philosophy to Culture", West describes four presuppositions necessary as prerequisites to object thinking:

• Everything is an object.
  
• Simulation of a problem domain drives object discovery and definition.
  
• Objects must be composable.
  
• Distributed cooperation and communication must replace hierarchical centralized control as an organizational paradigm.
  

Here is what he says about the fourth presupposition.

"Consider one of the more widely used models in traditional software development, the program structure chart (Figure 3-1) [I don't have figure 3-1, so we can look at this instead: http://en.wikipedia.org/wiki/File:CPT-Structured_Chart_Example.svg ], popularized by Meillor Page-Jones. At the top of the chart is the puppet master module, attended to by a court of special-purpose input, transform, and output modules. The puppet master incorporates all the knowledge about the task at hand, the capabilities of each subordinate module, and when and how to invoke their limited capabilities. The same thinking characterizes structured source code, wherein a main-line routine (frequently a Case statement) consolidates overall control. Each paragraph of a collection of special-purpose subroutine paragraphs is individually invoked and given limited authority to perform before control reverts to the main line.

Unlike puppet modules, objects are autonomous. They are protected from undue interference and must be communicated with, politely, before they will perform their work. It is necessary to find a different means to coordinate the work of objects, one based on intelligent cooperation among them.

It is sometimes difficult to conceive how coordination among autonomous objects can be achieved without a master controller or coordinator. One simple example is the common traffic signal. Traffic signals coordinate the movement of vehicles and people but have no awareness of what those other objects are about or even if any of them actually exist. A traffic signal knows about its own state and about the passage of time and how to alter its state as a function of elapsed time. In this model, the necessary "control" has been factored and distributed. The traffic signal controls itself and notifies (by broadcasting as a different color) others of the fact that it has changed state. Other objects, vehicles, notice this event and take whatever action they deem appropriate according to their own needs and self-knowledge."

Philip

On Tuesday, 22 October 2013 14:36:07 UTC+1, Nat wrote:

It's nothing to do with threads.  Smalltalk has reactive objects, not active (actor-like) objects.

The distinction that David West is drawing is between a program having a single entry point that delegates control to sub-modules, and between a program being a collaborating web of live objects that are sending messages to one another and that you modify to define system behaviour.

As Kevlin Henney has put it, you *can* do object-oriented programming in Java, but it does take some effort.

--Nat

On 22 October 2013 13:58, Alfredo Casado <casado....@gmail.com> wrote:

This style is more similar to the actor's models we can see in languages like erlang or scala (scala integrated akka actors model in the language in the last versions). Each object/actor have data, behavior and its own running thread, this actors/objects receives messages asynchronously and this enforces a tell don't ask style. It's difficult to think in this style when we use languages in which "sending a message to an object" its more "calling a function with implicit state".

Perhaps have each object in his own individual thread it's too much (think in a java program and each string having its own thread). How do you think about mix this style with functional decomposition or with "C++/java/etc" object oriented decomposition?, i see the actors/objects like element bigger than objects, and i don't sure if the typical rules or principles we apply like SRP can be applied to actors or we need to redefine those principles.

2013/10/22 Nat Pryce <nat....@gmail.com>

He doesn't say that.  He says that (paraphrased) every Java program starts with a thread of control running a main method, and you program by writing a main method to do something, and breaking down what it does into subordinate procedures and/or classes and objects.

Compare with a Smalltalk program in which there are lots of objects *already running*. Some of those objects translate between Smalltalk messages and hardware interrupts, for input, or control registers, for output, (usually via the OS these days). You program by modifying objects that are already running or creating new ones, and make your program do I/O by connecting your objects to those that interface with the hardware.

On 21 October 2013 19:13, Raoul Duke <rao...@gmail.com> wrote:

i don't understand what he means by saying every java class is a
program with a main(). i also don't understand why he claims
javascript has classes. there's probably other things i won't grok.
:-)

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
http://www.natpryce.com

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
http://www.natpryce.com

[philip schwarz]

He is saying that languages like Java encourage us to adopt the program structure chart approach to program decomposition.

At '17:"16 he talks about the PSC (program structure chart):

"The idea is that you have a master control module, where all the decisions are made, the master control module receives all the data required to make decisions about what has to be done in the program, uses afferent modules to bring data in, to formulate it, and format it, and put it into a process where it can be used, then it sends it down to transform modules that actually make the changes, and then uses the set of efferent modules to format it and output it from the system in some form or another. 

That was the most respected architecture for a program and everybody did it, everybody followed it, all of your programming languages, everything you were taught in school in that era was based upon this kind of a notion, so along come languages like Java, and Java says, you know what, an object is really just a program, it has a main, and it calls a bunch of subroutines which are methods, so it replicates, in Java you cannot create a class if it is not an implementation of this old program structure chart kind of a notion. Hierarchical control is something

that we don't give up easily in the profession. "

Philip 

[philip schwarz]

The book "Software Engineering: Principles and Practice"  describes 

three classical design methods: 

############################################ 

1) functional decomposition, which is a rather general approach to system design, not tied to any specific method 

2) data flow design, as exemplified by SA/SD; 

3) design based on data structures, as is done in JSP and JSD. 

############################################ 

Of these methods it says that they concentrate on identifying the functions of the system. 

Of the flow design, it says: "The data flow design method originated in the early 1970s with Yourdon and Constantine. In its simplest form, data flow design is but a functional decomposition with respect to the flow of data. A component is a black box which transforms some input stream into some output stream. In data flow design, heavy use is made of graphical representations known as data flow diagrams (DFDs) and structure charts." 

I think that while here West is talking specifically about program structure charts, he is generally critical of decomposing a system using functions and/or data. He advocates decomposing systems using behaviour.

See below for my excerpts from "Object Thinking" (not necessarily in the same order as in the book) to give you an idea of how West advocates using behaviour to decompose a system, rather than functions or data.

Object-oriented ideas and principles are poorly understood 

...Why does Alan Kay say the object revolution has yet to occur? ...[because] software developers tend to be so focused on what and how that they forget to explore questions of why. 

...Thirty plus years have passed since Alan Kay coined the term object-oriented...The ubiquity of object terminology does not mean, however, that everyone has mastered object thinking. Nor does the popularity of Java. Nor does the de facto standardization of object modeling embodied in UML. 

...An argument can be made that the contemporary mainstream understanding of objects is but a pale shadow of the original idea. Further, it can be argued that the mainstream understanding of objects is, in practice, antithetical to the original intent. 

...Thinking like a computer is the prevailing mental habit of traditional developers...begin by thinking what a computer has to do first and write that down; then think about what the computer has to do next, and continue that way until you have described the last thing the computer must do (David Parnas)...Object thinking focuses our attention on the problem space rather than the solution space. Object thinkers take the advice of Plato, Parnas, Fred Brooks, Christopher Alexander, and many others byletting the problem define its own solution...they are not thinking about the structure of a computer program; they are talking about finding the naturally occurring divisions and classifications ("natural joints") in the problem space. This is essential because the naturally occurring modules in a problem space are not isomorphic (exhibiting fitness between context and solution) with the modules discovered and defined when you are thinking about the design of a computer program. But they can be. 
Thinking like an object will lead to a greater degree of isomorphism between objects found in the problem space (the enterprise domain) and those in the solution space (the computer program) than thinking like a computer. Isomorphism of the modules (objects) in problem and solution space is a desirable, in fact essential, quality for software...the leading advocates of "behavioural objects", Kent Beck and Ward Cunningham invented the CRC card approach to finding and defining objects, the most popular of the "behavioural methods" 

...Plato suggests three things: decomposition is hard (and anyone really good at it deserves adoration), any decomposition that does not lead to the discovery of things that can be recombined—composed—is counterproductive, and the separation of one thing into two should occur at “natural joints.” By implication, if you decompose along natura joints—and only if you do so—you end up with objects that can be recombined into other structures. Also by implication, the natural joints occur in the domain, and “bad carving” results if you attempt to use the wrong “knife”—the wrong decomposition criterion...Decomposition is accomplished by applying abstraction—the “knife” used to carve our domain into discrete objects...Traditional computer scientists and software engineers have used data (attributes) or functions (algorithms) to decompose complex domains into modules that could be combined to create software applications. This parallels Edsger Wybe Dijkstra’s notion that “a computer program equals data structures plus algorithms.” 

...The fact that a computer program consists of data and functions does not mean that the nonsoftware world is so composed. Using either data or function as our abstraction knife is exactly the imposition of artificial criteria on the real world—with the predictable result of “bad carving.” The use of neither data nor function as your decomposition abstraction leads to the discovery of natural joints. David Parnas pointed this out in his famous paper “On Decomposition”(http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf). 

...Parnas' paper examined two conceptual abstractions for decomposing complex systems for the purposes of developing software. One was top-down functional decomposition, the approach that was gaining widespread acceptance under the label "structured design". Functional decomposition is based on an attempt to model the performance of the computer and software and to translate the requirements of the domain problem into those computer-based constructs.  Parnas offered an alternative approach called "design decision hiding" [self: hiding of decisions which are difficult or changeable], in which the problem or problem domain is modeled and decomposed without consideration of how the component parts of that domain or problem would be implemented. He was able to show thathis alternative led to simpler, easier to read, easier to maintain, and more composable software modules than functional decomposition. Unfortunately his advice was essentially ignored as the juggernaut of structured development came to dominate, at least officially, the manner in which software was conceived and implemented.

...Parnas, like Plato, suggests that you should decompose a complex thing along naturally occurring lines, what Parnas calls “design 
decisions.” 
...Both data and function are poor choices for being a decomposition tool. Parnas’s predictions have consistently been demonstrated as the industry blithely ignored his advice and used functional decomposition as the primary tool in program and system design for 30 years (40 if you recognize thatmost object development also uses functionality as an implicit decomposition criterion ). Using data as the decomposition abstraction leads to a different set of problems. Primary among these is complexity arising from the explosion in total data entities required to model a given domain and the immense costs incurred when the data model requires modification. 
What criterion should be used instead of data or functions? Behavior! ...Behavior is the key to finding the natural joints in the real world. This means, fortunately, that most of our work has already been done for us. Software developers simply must listen to domain experts. If the domain expert has at hand a name (noun) for something, there is a good chance that that something is a viable, naturally carved, object. ...Only when we are confident that our understanding of the domain and of its decomposition into objects mirrors that of the user and the natural structure of that domain should we begin to worry about how we are going to employ that understanding to create software artifacts. 

... If we “think in Java,” don’t we “think like objects” instead of engaging in the kind of “computerthink” discussed by Parnas? Unfortunately, no...Although you can implement object thinking in any programming language, knowing an “OO” language is not sufficient to engender object thinking...Languages such as Java and object-modeling tools such as UML effectively define an object as the encapsulation of data structures and algorithms. According to this kind of definition, an object is nothing more than a very tiny COBOL program... A COBOL program is the encapsulation of data structures (data division) and algorithms that operate on those data structures (procedure division)...developers tend to perpetuate old thinking habits, albeit sometimes to a lesser degree. 

...It’s useful to generalize Parnas’s observation to accommodate datacentric development and development in nonprocedural languages 
such as Prolog and Lisp. The essence of thinking like a computer is thinking in terms of the means of problem solution. You view every development problem through the lens of the means you intend to use to solve that problem. In datacentric development, the means of solution consists of relations and relationships; for Prolog and LISP, a set of propositions or state declarations. 
...The generalization being made here is a variant of the adage, “If your only tool is a hammer, every problem looks like a nail.” 
Following Parnas, I’m suggesting that software development has been distorted and that all the problems noted by Parnas persist because “our only tool is a computer, so every problem looks like a virtual machine.”... 

Philip

[Ben Biddington]

Why is function not considered a natural joint?

West quips about pointing out a function in the room - but don't functions occur just as naturally as objects?

(Is it Meyer who writes similarly that something less volatile than a system's main function is required for sustainable decomposition?)

How does function differ from behaviour?

What's so wrong with this picture?: http://en.m.wikipedia.org/wiki/Structure_chart

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

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

[Uberto Barbini]

Thanks philip for the retweet :)

On Sat, Nov 2, 2013 at 5:03 PM, philip schwarz
<philip.joh...@googlemail.com> wrote:
> Hey Uberto,
>
> on slide 18 you lay down some Mocking rules. The first one is "At most one
> mock and many stubs". The second one is "Use stubs for internals and close
> friends, mocks for collaborators (i.e. listeners)".
>
> Firstly, if you are at all able to elaborate on these I would appreciate it.

Let me fist explain that I meant rules as in "think twice before break
this rule" :)

Now I think that, with a well designed code, you probably shouldn't
need to mock more than one object for test.
I mean mock here in as strict sense of a behavior verified double.
All the other collaborators should be either concrete or stubbed
(preloaded with answer).

Why is this?

First I think we can all agree that mocks are more complicated both to
read and write than stubs, so having cleaner tests is an advantage.
Moreover if you are trying to tests too many things in a single test
then the tests will become brittle and you couldn't really listen to
them anymore.

Since internals, by definition, are very near to the class actually
under tests using concrete classes or stubs should be enough to test
them using state. I think behavioral tests are useful for
"contracting" between relatively distant classes, but could lead to
over baroque-style tdd (copyright Giovanni Asproni :)).

But as I said I mean this more like a alarm than an actual rule, that
is if you see yourself writing more than a mock, you should ask
yourself if this is really necessary or not, and in case if

Is this helping?

> Recently you said that all in all you liked Osherove's book. Was Osherove's
> guideline partly the inspiration for your two Mock rules above?

Yes, definitely reading Osherove's book gave me new ideas and let me
compare my experience with his. I also had no experience on dotNet
testing and it helped me there.
But most of the conference material came from another source, working
on a mock-happy codebase with far too many tests and an incredibly
obfuscated design.
Moreover, differently from Osherove, I suggest to stub object creating
concrete implementation of interfaces, rather than using framework to
create stubs.

ciao

Uberto

[Nat Pryce]

On 3 November 2013 19:50, Uberto Barbini <ube...@ubiland.net> wrote:

Since internals, by definition, are very near to the class actually
under tests using concrete classes or stubs should be enough to test
them using state. 

Maybe you're using the term "internal" differently from the way we do in the 

GOOS book.  In our terminology, an "internal" of an object is hidden and 

encapsulated behind the object's programming interface. When using (or 

testing) an object, the existence of its internals is unknown. If it's possible 

to stub (or mock) an object used by the object under test, the object being

stubbed/mocked is not, by definition, an internal of the object under test.

--Nat.

--
http://www.natpryce.com

[Uberto Barbini]

Sorry for the confusion. I was speaking in a wider sense but of course
you're correct.
What I meant is that kind of collaborators that are injected but still
work "internally" to an object, without reference to other "external"
objects.
for example
car = new Car(new Engine); //engine being the "internal"

Actually, in the examples of "bad code" there was something like this:

when(myPub.getMessageFactory()).thenReturn(myMsgFactory);

in this particular case there was no point in mocking MessageFactory
at all, and I suggested to transform it in a real internal, not need
to be injected since there is really no alternative behavior.
In another similar cases I suggest a simple concrete Stub, reusable in
other tests, instead of using mocking framework created doubles.

mySource = new SimpleBusSource(); //simple stub for testing purposes
myFetcher = new DataFetcher(mySource);

Instead where the injected object is more "indipendent", then it is
likely that I need to verify all the methods called, so a mock can
give me more value.

I hope it's a bit clearer now.
Unfortunately I was short of time and I changed the slides until the
same morning... :)



Uberto