Let's get the "Is TDD dead?" panel to talk about "mocks returning mocks returning mocks"

[philip schwarz]

The panel (@martinFowler @KentBeck and @dhh) of the "Is TDD dead?" Google Hangout https://plus.google.com/events/cco30ri6dpkej4h4d8mejmat98o have invited spectators to put forward questions for the final part of the debate. 

IMHO It would be a shame if we missed the opportunity to ask them to talk about "mocks returning mocks returning mocks" and the important points so effectively described by @garybernhardt in "Test Isolation Is About Avoiding Mocks" https://www.destroyallsoftware.com/blog/2014/test-isolation-is-about-avoiding-mocks. 

If the topic matters to you, how about putting forward your questions, so there is a better chance of the topic being debated? 

To propose a question, just click play on the video you see on the hangout page.

Philip Schwarz

[philip schwarz]

First request:

+Kent Beck +Martin Fowler Please, please, follow up on the following:

@KentBeck TIL what "tell, don't ask" really means. horrified.
@martinfowler @kentbeck I realize I forgot to ask you about that during the hangout :-(

[philip schwarz]

Second Question:

+Kent Beck  I would really like to know how your view of the "Law of Demeter" compares to the following:

+David Heinemeier Hannson  "pseudoscience" [1]
+Martin Fowler  "stepping stone towards co-locating behavior and data...not worth highlighting" [2]
+Nat Pryce  : "OO code that follows LoD is easier to understand and maintain" [3]
+Allen Holub  "the primary directive of OO systems" [4]

[1] RailsConf 2014 - Keynote: Writing Software by David Heinemeier Hansson
[2] http://martinfowler.com/bliki/TellDontAsk.html
[3] http://www.mockobjects.com/2006/10/tell-dont-ask-and-mock-objects.html
[4] http://tinyurl.com/ml3oss4 + http://www.drdobbs.com/testing/testing-oo-systems-part-1/240000411 

On Sunday, 1 June 2014 07:01:31 UTC+1, philip schwarz wrote:

[philip schwarz]

Third Question:

+Kent Beck  +Martin Fowler +David Heinemeier Hannson Can you please discuss the point made by +Gary Bernhardt on your following exchange in part 1 of this hangout:

+Kent Beck : "I just don't go very far down the mock path. I look at code where you have mock returning mocks returning mock and my experience is if I have, if I use TDD I can refactor stuff, and then I heard these stories, people say "well I use TDD and now I can't refactor anything" and like I could not understand that, and then I started looking at their tests and well, if you have mocks returning mocks returning mocks, your test is completely coupled to the implementation, not the interface, but the exact implementation of some object, you know, three streets away, of course you can't change anything without breaking the test. So that for me is too high a price to pay.That is not a trade off I am willing to make just to get piecemeal development
+Martin Fowler: "And this is I think much at the heart of this. Confusion about over terminology And what these different things are. When I read David's initial blog post...one of the things that came through very clearly was his criticism of TDD and of how the design damage that comes/flows through it has in itself tied in a notion of the strong desire for isolation and mocking. And it is very important to point out that there is nothing within the idea of how you do either TDD or unit testing that says you have to have that kind of isolation. Some people are very much in favour of it, others aren't...Our style of testing, we don't bother with isolation and you know, it is working very well for us, thank you very much. So that is one thing, wheter TDD and Unit testing should be tied in with the idea of isolation, and I look at it as different schools of thought, and I am with Kent, I hardly ever use mocks, but I know good people who do, so I don't want to shoot everybody who uses mocks, maybe give it 10 more years and then we'll drum them out or something, we'll see."  

+Gary Bernhardt  wrote a great blog post called "Test Isolation Is About Avoiding Mocks" https://www.destroyallsoftware.com/blog/2014/test-isolation-is-about-avoiding-mocks.

+Kent Beck  +Martin Fowler  +David Heinemeier Hannson  Can you discuss the point he makes in the post?
Here are the post's concluding thoughts:

"This post was triggered by Kent's comment about triply-nested mocks. I doubt that he intended to claim that mocking three levels deep is inherent to, or even common in, isolated testing. However, many others have proposed exactly that straw man argument. That argument misrepresents isolated testing to discredit it; it presents deep mocks, which are to be avoided in isolated testing, as being fundamental to it; it's fallacious. It's at the root of the claim that mocking inherently makes tests fragile and refactoring difficult. That's very true of deep mocks, but not very true of mock-based isolation done well, and certainly isn't true of isolation done without mocks.

In a very real sense, isolated testing done test-first exposes design mistakes before they're made. It translates coupling distributed throughout the module into mock setup centralized in the test, and it does that before the coupling is even written down. With practice, that preemptive design feedback becomes internalized in the programmer, granting some of the benefit even when not writing tests. There may be other paths to that skill, but I'm still learning from my tests after seven years of isolating around 50% of the time. This path also happens to produce a trail of sub-millisecond tests fully covering every component designed using it, which is alright with me."

On Sunday, 1 June 2014 07:01:31 UTC+1, philip schwarz wrote:

[Grzegorz Gałęzowski]

I don't think they are the ones fit best to answer this question. I do not question their abilities, it's just that both Kent and Martin do not appear to value the design approach that makes mock objects useful. What kind of in-depth analysis can we expect from them?

I am really, really missing the "mock objects" perspective in this "Is TDD dead?" discussion, but I doubt that any of the panelists can provide one. Unless e.g. Steve or Nat are able to join the discussion, I'm afraid we'll have what we'll have.

regards,

grzesiek

[Grzegorz Gałęzowski]

That being said, I +1'd all your questions.

[philip schwarz]

Grzegorz,

thanks for the upvotes, much appreciated.

Philip

[philip schwarz]

I don't think we can expect too much... yesterday Kent Beck wrote Learning About TDD: The Purpose of #isTDDDead in which he says "if you want to hear a balanced debate about mocks, that seems like an interesting topic, but this is not the place.

Philip

[Matt Wynne]

Maybe we should invite Kent / Martin onto the Kickstart Academy podcast for a chat with Nat / Steve about that topic?

https://www.youtube.com/watch?v=u-d2v_8YYw4

--

---
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/d/optout.

cheers,

Matt

---

ma...@mattwynne.net

[Malte Finsterwalder]

It sounds like a very interesting idea to get Steve, Nat, Martin and Kent together to talk about mocks and isolation in unit testing.

Would love to see that!

Greetings,

   Malte

[Grzegorz Gałęzowski]

+1 from me, especially that as far as I remember, Kent wrote a foreword to GOOS, so he must be familiar with the content and the authors.

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/d/optout.

cheers,

Matt

---

ma...@mattwynne.net

[Nat Pryce]

I'd be up for it if you can make it happen.

--
http://www.natpryce.com

[Steve Freeeman]

We can ask Kent (assuming he's not on this list). Arlo Belshee has a similar position, although most of it feels like disagreement over naming to me.

I suggest we don't do it live so we can edit it down, and a shared whiteboard might be useful.

S

[philip schwarz]

I had completely forgotten about that! 

One line from the foreword: "The style of test-driven development presented here is different from what I practice."

Philip

[philip schwarz]

any news on the idea of a get together with Kent Beck and Martin Fowler to talk about mocks and isolation in unit testing?

Philip

[Steve Freeman]

We contacted Kent. It's up to Matt Wynne now. 

S

Steve Freeman

http://www.higherorderlogic.com

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

[philip schwarz]

great news, thanks.

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

[Thiago Ramos]

+1 from me but i think that @dhh need to get into this conversation with nat and steve too. Because it was him that started all this bullshit and i really love to see nat or/and steve talk with him about this topic. Because, from what i saw in the "Is TDD dead" videos is that kent and martin don't want stand for what they think is right. 

Well, this is my opinion.

Thanks.

[Steve Freeeman]

I don't want to get into this discussion, except to say that I'm not sure that including DHH in our call will be helpful. We're more about what to do once you've agreed that TDD is worth the trouble.

S

[Matt Wynne]

Agreed! I’m really looking forward to it.

> --
>
> ---
> 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/d/optout.

cheers,
Matt

---
ma...@mattwynne.net

[Gishu Pillai]

On Sat, Jun 14, 2014 at 10:52 PM, philip schwarz <philip.joh...@googlemail.com> wrote:

any news on the idea of a get together with Kent Beck and Martin Fowler to talk about mocks and isolation in unit testing?

Philip

Thanks Philip for sharing that... An interesting discussion to listen in on.

That said, not sure what the proposed meet is going to achieve .. more precisely asking Classicists/State based approach to talk about something that they don't advocate or practice. (Except maybe to understand their reasons for not preferring this alternative)

The Is TDD dead raises some issues that I've seen out in the wild as well. I was a TDD fanatic a few years ago but have toned down quite a bit to a point where I don't do it all the time myself :)

Maybe the things that I have to say will need the length of a blog post.

- some (or most depending on where you work) prefer tinkering with the code to learn or try something out. The tests just get in the way. Like DHH said, they have to 'see' the changes to understand what they are trying to do.. much less figure out the test for the same

- the TDD horse is easy to get on to but hard to stay on. Kent and others have laid out easy / catchy guidelines that beginners easily grasp.  But the real secret sauce - the refactoring step OR 'listening to the tests' is often missed or not done thoroughly. Instead of seeing the difficulty/inability to write a quick test as a design problem, many use Mocks as a 'get out of this soup' free card and duct tape their way out. They mock each and every collaborator in every test - in short set up a ticking time bomb. This also causes the interface explosion issue - to mock every other type that is causing me grief, I need an interface in between. The concept of Roles hasn't been talked out enough.

It's an awareness/education issue but it is hurting the credibility of TDD in the large + causing the vehement outbursts against interaction-based TDD. The intermediate stage needs more discussion... specifically outlining 'what not to do' (on the lines of TDD anti-patterns by James Carr n later on StackOverflow), which seems to be tripping most people up.

Gishu

 

[Matt Wynne]

On 21 Jun 2014, at 05:02, Gishu Pillai <gishu....@gmail.com> wrote:

On Sat, Jun 14, 2014 at 10:52 PM, philip schwarz <philip.joh...@googlemail.com> wrote:

any news on the idea of a get together with Kent Beck and Martin Fowler to talk about mocks and isolation in unit testing?

Philip

Thanks Philip for sharing that... An interesting discussion to listen in on.

That said, not sure what the proposed meet is going to achieve .. more precisely asking Classicists/State based approach to talk about something that they don't advocate or practice. (Except maybe to understand their reasons for not preferring this alternative)

To be clear, the proposal is to have a conversation between Kent Beck and the GOOS authors to exchange ideas and perspectives about how TDD helps them with their designs in different ways.

We’re still waiting for Mr. Beck to get back to us about his availability, but I’m hopeful.

cheers,

Matt

---

ma...@mattwynne.net

[philip schwarz]

Hello Matt,

did Kent Beck find the time to get back to you about his availability?

Thanks,

Philip

[Matt Wynne]

I’m afraid he’s gone dark on us. Sorry! I’m not sure how much it’s OK to keep badgering him… :(

--

---
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/d/optout.

cheers,

Matt

---

ma...@mattwynne.net

[philip schwarz]

What a shame, I was really looking forward to it. Yes, I can't imagine him appreciating too much insistence. Well, thank very much for trying.

Philip

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/d/optout.

cheers,

Matt

---

ma...@mattwynne.net

[philip schwarz]

On 27 Sep, Chris Parsons tweeted:

@chrismdp If I was to put together a panel at a UK conference to discuss the question "Is TDD dead?", who would you want to be on that panel?

Like a few others, I made my suggestions, but did not hear from him again on the subject, so I asked him and he said that he was asked to host a panel at the internal BBC tech conference, which is not open to the public.

Does anyone in the group work at the BBC? If the outcome/proceedings of the panel turns out to be noteworthy then it would be nice if it could be divulged.

Philip

On Thursday, 17 July 2014 11:24:34 UTC+1, Matt Wynne wrote:

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/d/optout.

cheers,

Matt

---

ma...@mattwynne.net

[philip schwarz]

I asked @chrismdp if he will divulge the outcome of the panel if it turns out to be noteworthy, and he said he surely will.

Philip

[Seb Rose]

 

I'm on the panel and I'll corroborate ;)

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

[philip schwarz]

Great, thanks.

Philip

[philip schwarz]

Is TDD Dead?

A session at { develop: BBC } 2014

Thursday 13th November, 2014

 

1:30pm to 3:00pm (GMT)

There’s been a lot of discussion recently about TDD’s usefulness and whether or not it has run its course as a methodology. Come along and hear a panel of experts in the field discuss whether any of this is true, what the key questions are, and what this means for all software developers.

http://lanyrd.com/2014/developbbc/sdgfpr/

Philip

On Sunday, 5 October 2014 21:40:19 UTC+1, philip schwarz wrote:

[Serkan Camurcuoglu]

is it recorded?

[philip schwarz]

So far I have not been able to find a video.

Philip

[philip schwarz]

According to https://twitter.com/TheBBCAcademy/status/532946717558456320, "The end of a fantastic #developbbc 2014 - but it will live online. Sessions from Salford and London coming soon."

Philip

On Friday, 14 November 2014 08:47:44 UTC, Serkan Camurcuoglu wrote:

[Seb Rose]

As far as I am able to determine it is not publicly available. The organiser said that it *might* be made available in due course.

Seb

---

From: philip schwarz
Sent: ‎18/‎11/‎2014 23:14
To: growing-object-o...@googlegroups.com
Subject: Re: [GOOS] Let's get the "Is TDD dead?" panel to talk about "mocksreturning mocks returning mocks"

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

[Steve Freeman]

So, perhaps someone could summarise any interesting comments.

S

[Seb Rose]

---

From: Steve Freeman
Sent: ‎19/‎11/‎2014 09:19

To: growing-object-o...@googlegroups.com
Subject: Re: [GOOS] Let's get the "Is TDD dead?" panel to talk about"mocksreturning mocks returning mocks"

[Nat Pryce]

Seb... are you saying there were no interesting comments? :-)

--

http://www.natpryce.com

[Seb Rose]

 

 

On Wed, 19 Nov 2014, at 12:49 PM, Nat Pryce wrote:

Seb... are you saying there were no interesting comments? :-)

 

I wan't intending to... but then again.....

 

I think the panel broadly agreed that:

1) TDD is a technique in the tool box that (still) has its uses... so it's not dead

2) Dogmatic adherence to almost anything is not usually a good idea

3) However, less experienced developers may benefit from a dogmatic approach while they acquire skills

4) Anything that can be done well can also be done badly - including TDD and, more generally, testing.

 

I also liked Ellie's use of aesthetics as a guide to tell whether code was good or not - similar to the more common use of the 'smell' analogy.

 

 

 

--

The Cucumber for Java Book - Seb Rose, Matt Wynne & Aslak Hellesøy

Now available from the Pragmatic Press - https://pragprog.com/book/srjcuc/the-cucumber-for-java-book

 

 

[Nat Pryce]

Personally I'm uncomfortable wit "aesthetics" as a justification for engineering decisions because (channeling Zen and the Art of Motorcycle Maintenance) it means making decisions unconsciously. This means stopping at the "unconscious competence" level of learning and not progressing to the fifth learning level, at which you are able to help others reach mastery.

--Nat

[Anthony Green]

On 19 Nov 2014, at 12:59, Seb Rose <s...@claysnow.co.uk> wrote:

I think the panel broadly agreed that:

1) TDD is a technique in the tool box that (still) has its uses... so it's not dead

2) Dogmatic adherence to almost anything is not usually a good idea

3) However, less experienced developers may benefit from a dogmatic approach while they acquire skills

4) Anything that can be done well can also be done badly - including TDD and, more generally, testing.

I was there and watched it back afterwards, and that pretty much covers it. Nothing new or unexpected.  

[Steve Freeman]

I dunno. I thought "real" engineers did care about aesthetics. Perhaps not as a final arbiter, but certainly as a guide and as a sign of professional skill.

S

[Nat Pryce]

I did try to be a bit controversial but obviously wasn't anywhere near incendiary enough.

--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/d/optout.

--

http://www.natpryce.com

[Seb Rose]

On Wed, 19 Nov 2014, at 01:07 PM, Nat Pryce wrote:

Personally I'm uncomfortable wit "aesthetics" as a justification for engineering decisions because (channeling Zen and the Art of Motorcycle Maintenance) it means making decisions unconsciously. This means stopping at the "unconscious competence" level of learning and not progressing to the fifth learning level, at which you are able to help others reach mastery.

 

Is that the 5th level?

 

The Dreyfus paper says level 5 is: "intuitive grasp of situations based on deep, tacit understanding". Aesthetics seems to fit into this space, doesn't it?

[Nat Pryce]

I wasn't using the term as used in Dreyfus' model of learning but as used as an extension the Four-Stages of Competence model.  I should have said "fifth stage" rather than "fifth level". To quote from wikipedia (http://en.wikipedia.org/wiki/Four_stages_of_competence), the fifth stage is when...

 "the person has not only mastered the physical skill to a highly efficient and accurate level which does not any more require of him conscious, deliberate and careful execution of the skill but instead done instinctively and reflexively, requiring minimum efforts with maximum quality output, and is able to understand the very dynamics and scientific explanation of his own physical skills. In other words, he comprehends fully and accurately the what, when, how and why of his own skill and possibly those of others on the same skill he has. In addition to this, he is able to transcend and reflect on the physical skill itself and be able to improve on how it is acquired and learned at even greater efficiency with lower energy investment. Having fully understood all necessary steps and components of the skill to be learned and the manner how they are dynamically integrated to produce the desired level of overall competence, he is thereby able to teach the skill to others in a manner that is effective and expedient." (Lorgene A Mata, PhD, December 2004)^[2]

[Seb Rose]

Very "Hitch-hikers guide to the galaxy" having a fifth stage in a four stage system.

 

Also, quite zen having "enlightened competence".

 

--

The Cucumber for Java Book - Seb Rose, Matt Wynne & Aslak Hellesøy

Now available from the Pragmatic Press - https://pragprog.com/book/srjcuc/the-cucumber-for-java-book

 

 

[philip schwarz]

>Dogmatic adherence to almost anything is not usually a good idea

I liked the model Kent Beck comes up with in "When TDD Doesn't Matter" [1] to explain to his students that TDD is not like flossing (we should do it), it is a small part of a large and complicated 3D feedback space, and must not be treated as a ritual to be aped.

Philip

[1] (July 2014) https://www.facebook.com/notes/kent-beck/when-tdd-doesnt-matter/797644973601702

On Wednesday, 19 November 2014 12:59:23 UTC, Seb Rose wrote:

 

 

On Wed, 19 Nov 2014, at 12:49 PM, Nat Pryce wrote:

Seb... are you saying there were no interesting comments? :-)

 

I wan't intending to... but then again.....

 

I think the panel broadly agreed that:

1) TDD is a technique in the tool box that (still) has its uses... so it's not dead

2) Dogmatic adherence to almost anything is not usually a good idea

3) However, less experienced developers may benefit from a dogmatic approach while they acquire skills

4) Anything that can be done well can also be done badly - including TDD and, more generally, testing.

 

I also liked Ellie's use of aesthetics as a guide to tell whether code was good or not - similar to the more common use of the 'smell' analogy.

 

 

 

--

The Cucumber for Java Book - Seb Rose, Matt Wynne & Aslak Hellesøy

Now available from the Pragmatic Press - https://pragprog.com/book/srjcuc/the-cucumber-for-java-book

 

 

On 19 November 2014 10:30, Seb Rose <s...@claysnow.co.uk> wrote:

 

---

From: Steve Freeman

Sent: ‎19/‎11/‎2014 09:19

To: growing-object-oriented-soft...@googlegroups.com

Subject: Re: [GOOS] Let's get the "Is TDD dead?" panel to talk about"mocksreturning mocks returning mocks"

 

So, perhaps someone could summarise any interesting comments.

 

S

 

 

On 18 Nov 2014, at 23:25, Seb Rose <s...@claysnow.co.uk> wrote:

> As far as I am able to determine it is not publicly available. The organiser said that it *might* be made available in due course.

 

--

 

---

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/d/optout.

--

 

---

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/d/optout.

 

 

 

--

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.

[philip schwarz]

>I also liked Ellie's use of aesthetics as a guide to tell whether code was good or not - similar to the more common use of the 'smell' analogy.

Just in case someone finds it interesting, back in 2008 Robert Martin blogged on "Quintessence: The fifth element for the Agile Manifesto" [1] and in one of my comments I mentioned Kent Beck's mantra: ‘Make it run, make it right, make it fast’ [2], and someone replied with "My variant is 'first make it work then make it pretty.'""

See below for my response:

You said: “first make it work then make it pretty”.

Since you value Beck’s mantra’, it is likely that you are using ‘pretty’ to mean ‘right’/’good’/’clean’. If so, then, on the one hand I find your usage of ‘pretty’, acceptable because ‘pretty’ is the antonym of ‘ugly’, and I am quite comfortable referring to bad code as ‘ugly’. But on the other hand I object to it because when I read ‘first make it work then make it pretty’ I can’t help thinking that ‘pretty’ is being used in a pejorative sense and that you really mean ‘I favour function (making it work) over form (making it pretty/beautiful) because the latter has less/little/no value’.

If however you are using ‘pretty’ to mean ‘pleasing to the senses, but of little/no utilitarian value’, then maybe you disagree that there is a third state between ‘functionally correct’, and ‘fast’, where aesthetics matter: ‘well written’.

In Smalltalk Best Practice Patterns, Kent Beck is not afraid of using the word ‘style’: ‘Good programming style is one of those things that everyone knows when they see it but is very hard to articulate precisely’. The book teaches us patterns for writing code with good style.

In Essential Java Style – Patterns for Implementation, Jeff Langr uses Beck’s patterns (adding some of his own) to teach us how to write clean code. While he uses the term ‘style’ in the title, he says that ‘Style is an imprecise word: the word style connotes flash, panache, coolness…[which does not] accurately describe the goal of this book, which is why it has a subtitle: ‘Implementation patterns’.

In his latest book, Implementation Patterns, Beck has a compelling definition of programming style: ‘These three elements – values, principles, and patterns – form a balanced expression of a style of development. The patterns describe what to do. The values provide motivation. The principles help translate motive into action. ... The result is a style of development, not the style of development. Different values and different principles will lead to different styles.

In Agile Software Development – Principles, Patterns, and Practices, Uncle Bob is not afraid to talk about beauty: ‘What does it take to make a module easy to read and easy to change? Much of this book is dedicated to principles and patterns whose primary goal is to help you create modules that are flexible and adaptable. But it takes something more than just principles and patterns to make a module that is easy to read and change. It takes attention. It takes discipline. It takes a passion for creating beauty.’

Making code right/clean/beautiful/pretty(?) is very important.

In the preface to Implementation Patterns, Kent Beck says the following: ‘This book is built on a rather fragile premise: that good code matters. I have seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use.’ But then tells us that ‘writing good code is potentially profitable and that ‘coding well is satisfying, both the act itself and the knowledge that others will be able to understand, appreciate, use and extend my work’.

In his new book, Clean Code, Uncle Bob says that when he read the preface he thought: I disagree! I think the premise is one of the most robust, supported, and overloaded of all the premises in our craft (and I think Kent knows it). We know good code matters because we’ve had to deal for so long with its lack.

[1] http://web.archive.org/web/20120121212207/http://blog.objectmentor.com/articles/2008/08/14/quintessence-the-fifth-element-for-the-agile-manifesto  

[2] http://web.archive.org/web/20120121212207/http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast 

Philip

On Wednesday, 19 November 2014 12:59:23 UTC, Seb Rose wrote:

 

 

On Wed, 19 Nov 2014, at 12:49 PM, Nat Pryce wrote:

Seb... are you saying there were no interesting comments? :-)

 

I wan't intending to... but then again.....

 

I think the panel broadly agreed that:

1) TDD is a technique in the tool box that (still) has its uses... so it's not dead

2) Dogmatic adherence to almost anything is not usually a good idea

3) However, less experienced developers may benefit from a dogmatic approach while they acquire skills

4) Anything that can be done well can also be done badly - including TDD and, more generally, testing.

 

I also liked Ellie's use of aesthetics as a guide to tell whether code was good or not - similar to the more common use of the 'smell' analogy.

 

 

 

--

The Cucumber for Java Book - Seb Rose, Matt Wynne & Aslak Hellesøy

Now available from the Pragmatic Press - https://pragprog.com/book/srjcuc/the-cucumber-for-java-book

 

 

On 19 November 2014 10:30, Seb Rose <s...@claysnow.co.uk> wrote:

 

---

From: Steve Freeman

Sent: ‎19/‎11/‎2014 09:19

To: growing-object-oriented-soft...@googlegroups.com

Subject: Re: [GOOS] Let's get the "Is TDD dead?" panel to talk about"mocksreturning mocks returning mocks"

 

So, perhaps someone could summarise any interesting comments.

 

S

 

 

On 18 Nov 2014, at 23:25, Seb Rose <s...@claysnow.co.uk> wrote:

> As far as I am able to determine it is not publicly available. The organiser said that it *might* be made available in due course.

 

--

 

---

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/d/optout.

--

 

---

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/d/optout.

 

 

 

--

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.

[philip schwarz]

>I also liked Ellie's use of aesthetics as a guide to tell whether code was good or not - similar to the more common use of the 'smell' analogy.

In Dale Skrien's book, "OO design using Java" (btw don't be put off by the word 'Java'), he says that one way to measure the quality of a design is to analyse s/w with regard to the following properties, which he calls "the criteria for elegant software": 

USABILITY - is it easy for the client to use 
COMPLETENESS - does it satisfy all the client's needs 
ROBUSTNESS - will it deal with unusual situations gracefully and avoid crashing? 
EFFICIENCY - will it perform the necessary computations in a reasonable amount of time and using a reasonable amount of memory and other resources? 
SCALABILITY - will it still perform correctly and efficiently when the problems grow in size by several orders of magnitude 
READABILITY - is it easy for another programmer to read and understand the design and code? 
REUSABILITY - can it be reused in another completely different setting? 
SIMPLICITY - is the design and/or the implementation unnecessarily complex? 
MAINTAINABILITY - can defects be found and fixed easily without adding new defects? 
EXTENSIBILITY - can it easily be enhanced or restricted by adding new features or removing old features without breaking code? 

Skrien says "we will refer to software as elegant if it has these properties". He uses the term 'elegant' to remind the reader that s/w design is as much an art as a craft." 

Here are more excerpts: 

"I want to share [with students] my love of 'elegant' designs. I want them to develop a sense of aesthetics when it comes to s/w development, so that they can tell when code "smells bad" [Fowler's bad smells] and where it smells good. I want them to develop this sense to the degree that 'shivers of joy run up and down their spine' when they see elegant code and also that they would feel 'shudders of revulsion' when they see inelegant code. Donald Knuth said that computer programming is an art as well as a science, and involves creativity and beauty. I want my students to attempt to produce objects of beauty, like artists do. When successful, they should be sufficiently proud of their work that they want to sign it, as artists do." 

"How do yo know when your design is elegant? In this text, we will discuss, from an OO perspective, many design and implementation principles and patterns that can aid in the development and appreciation of elegant software. After enough practice using these principles and patterns, the reader can begin to develop a 'feeling' for quality software. That is, even though it is hard to precisely define such s/w, the reader will know it when they see it." 

"...this book is an introduction to many of the topics that you need to understand in order to start on the road to elegance in your own s/w development". 

Philip

On Wednesday, 19 November 2014 12:59:23 UTC, Seb Rose wrote:

 

 

On Wed, 19 Nov 2014, at 12:49 PM, Nat Pryce wrote:

Seb... are you saying there were no interesting comments? :-)

 

I wan't intending to... but then again.....

 

I think the panel broadly agreed that:

1) TDD is a technique in the tool box that (still) has its uses... so it's not dead

2) Dogmatic adherence to almost anything is not usually a good idea

3) However, less experienced developers may benefit from a dogmatic approach while they acquire skills

4) Anything that can be done well can also be done badly - including TDD and, more generally, testing.

 

I also liked Ellie's use of aesthetics as a guide to tell whether code was good or not - similar to the more common use of the 'smell' analogy.

 

 

 

--

The Cucumber for Java Book - Seb Rose, Matt Wynne & Aslak Hellesøy

Now available from the Pragmatic Press - https://pragprog.com/book/srjcuc/the-cucumber-for-java-book

 

 

On 19 November 2014 10:30, Seb Rose <s...@claysnow.co.uk> wrote:

 

---

From: Steve Freeman

Sent: ‎19/‎11/‎2014 09:19

To: growing-object-oriented-soft...@googlegroups.com

Subject: Re: [GOOS] Let's get the "Is TDD dead?" panel to talk about"mocksreturning mocks returning mocks"

 

So, perhaps someone could summarise any interesting comments.

 

S

 

 

On 18 Nov 2014, at 23:25, Seb Rose <s...@claysnow.co.uk> wrote:

> As far as I am able to determine it is not publicly available. The organiser said that it *might* be made available in due course.

 

--

 

---

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/d/optout.

--

 

---

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/d/optout.

 

 

 

--

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.

[philip schwarz]

A couple of tweets from Kent Beck:

29 Oct 2014 @KentBeck green tests and clean code can be too much all at once. forgive yourself. get to green, then keep it green while you add beauty.

14 May 2014 @KentBeck i hope i effectively convey to my students my joy in the beauty of code and they don't just think i'm an ocd wackjob.

Philip

[philip schwarz]

>I dunno. I thought "real" engineers did care about aesthetics. 

Some excerpts from a conversation [1] recorded by Ward Cunningham & Kent Beck at https://hacksummit.org/

18:04 Beck: nobody ever said to us, go write beautiful programs. we spent a lot of our time making programs beautiful, and there was no payoff, we weren't going to get better reviews or payraises or a pat on the back or anything, out of that, and yet if we hadn't, we wouldn't have accomplished what we accomplished. So, What happens in that beautification process?

Ward: Alexander argues that it is our innate ability to recognise utility, that beauty comes from utility, .... there could be something that we are priming, 

trying coding this way, trying coding that way, and see how this works out, and see how that works out, that we have a sense of, you know, what is going to be troublesome, and what isn't, and we might see that, but it is so subliminal, by that time, that, it is more likely you'll know it when you see it...

Beck: I talk about the problem spaces and solution spaces a lot, and I think the search for beauty, there are generally a few good ways of solving a problem, and there are a bazillion bad ways of solving the problem, and there is something about that search for beauty that lets you know what is uphill in the solution space, what is a more fitting solution, but how are you going to cultivate that, if your boss either isn't going to recognise you doing that or he is going to actively discourage you from doing that, and yet it is such a fundamental part of being an effective engineer, like how do you square that?

Ward: well, that is the difference between a programmer and a manager, a manager has lost that sense, if you had a manager walking around a manufacturing floor and he heard a machine squeaking, he'd say why is this machine squeaking, that can't be right? but a mgr walking around a floor full of programmers, he won't bother looking at the screens because it just says too much effort to even see what is going on. So I think as programmers we have an obligation to take that into our own hands and I kind of forget where it came out exactly, the term velocity, but I always thought that was kind of a measure you know you do the best work you can the best way you can and then you just observe, yes, this is the velocity I am getting, this is the velocity we are getting, it is a measure of good engineering, but, you know, somehow, it has become a measure of bad engineering, people say, well, can we improve that 20%? well yeah, if we want to get off of optimum, if you want lots of problems in the future, we could do that....if you want to do good work and spend a lifetime doing it, you have to have a sense of what it takes to get it done     

[1] https://www.youtube.com/watch?feature=player_embedded&v=ShOMGASbcJ0

Philip

[philip schwarz]

I was REALLY HOPING the panel would discuss the subject of how TDD turns testing into design.

Back in May 2014, when Martin Fowler asked for suggestions for topics for round two of "Is TDD Dead", I tweeted the following at @dhh @martinfowler @KentBeck @unclebobmartin @sf105 @natpryce: 

before debating the fallacy that "an easier to unit test system is a better designed system" and that "you can only prove your design by making it more testable" why not involve Steve Freeman and Nat Pryce who say (in GOOS): "We write our tests BEFORE we write code. Instead of just using testing to verify our work after it is done, TDD turns testing into a DESIGN activity. We use testing to clarify our ideas about WHAT we want the code to do. As Kent Beck described it to us, 'I was finally able to separate logical from physical design...'. We find that the effort of writing a test first also gives us rapid feedback about the quality of our design ideas - that making code accessible for testing often drives it towards being cleaner and more modular." 

That panel never addressed such topic either. :-(

Philip

[Steve Freeman]

I don't think we should expect any more activity from that group. It was a bit of an experiment, I'm not sure it added much to the debate.

S

[philip schwarz]

Jan 23rd 2015, Seb tweeted:

A panel discussion at BBC Academy "Is TDD dead?" with @chrismdp @feyeleanor @natpryce @jonpither @robchatley http://bbc.in/15vma3W 

Philip

P.S. actual link: http://www.bbc.co.uk/academy/technology/article/art20150120140255999

On Tuesday, 18 November 2014 23:25:54 UTC, Seb Rose wrote:

As far as I am able to determine it is not publicly available. The organiser said that it *might* be made available in due course.

Seb

---

From: philip schwarz
Sent: ‎18/‎11/‎2014 23:14

To: growing-object-oriented-soft...@googlegroups.com

[Grzegorz Gałęzowski]

Watching the panel, I was at first surprised to hear that depending on programming language we can test less, but then I recalled that C++ folks are mocking/testing constructors far more often than C#/Java folks their finalization methods...

grzesiek

[Nat Pryce]

I don't understand.  Mocking constructors or testing constructors?  I don't actually see how C++ makes that easier or harder than Java. Personally I prefer to *not* mock constructors (and other statically bound functions), to get faster design feedback.

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/d/optout.

--

http://www.natpryce.com

[Grzegorz Gałęzowski]

Sorry, I meant destructors. Mea culpa.

grzesiek

On Sunday, January 25, 2015 at 5:22:10 PM UTC+1, Nat wrote:

I don't understand.  Mocking constructors or testing constructors?  I don't actually see how C++ makes that easier or harder than Java. Personally I prefer to *not* mock constructors (and other statically bound functions), to get faster design feedback.

On 25 January 2015 at 14:20, Grzegorz Gałęzowski <grzesiek....@gmail.com> wrote:

Watching the panel, I was at first surprised to hear that depending on programming language we can test less, but then I recalled that C++ folks are mocking/testing constructors far more often than C#/Java folks their finalization methods...

grzesiek

On Sunday, January 25, 2015 at 11:58:13 AM UTC+1, philip schwarz wrote:

Jan 23rd 2015, Seb tweeted:

A panel discussion at BBC Academy "Is TDD dead?" with @chrismdp @feyeleanor @natpryce @jonpither @robchatley http://bbc.in/15vma3W 

Philip

P.S. actual link: http://www.bbc.co.uk/academy/technology/article/art20150120140255999

On Tuesday, 18 November 2014 23:25:54 UTC, Seb Rose wrote:

As far as I am able to determine it is not publicly available. The organiser said that it *might* be made available in due course.

Seb

---

From: philip schwarz
Sent: ‎18/‎11/‎2014 23:14

To: growing-object-oriented-softwar...@googlegroups.com

--

http://www.natpryce.com