|
This week there have been two interesting TDD webinars about why after 20 years it doesn't dominate the software development scene. To tell the truth, in some situations, it is even an unknown technique and therefore not adopted not by choice but out of ignorance.
My personal feeling (I have been in the software development field since 1995 and met extreme programming in 2001) is that in the last 20 years, starting from the rise of agile methodologies, there has been a clear bifurcation: on the one hand, craftmanship, extreme programming, people who apply to their profession that continuous improvement we preach. On the other hand, people who have learned from their predecessors (someone like me, possible), perhaps losing something, as if the transition between anticipatory and evolutionary design had been missing. We missed the design at all. Now my question is: how can we recover? It looks like a chicken egg problem. In the past a programmer learned design principles and techniques and then applied them (with all the disadvantages we know) but the process was clear and straightforward. Today if I started from scratch, under expert guidance, I would probably learn to program and design using TDD. But if I am already a programmer, maybe for 10 years (iterating the same bad year ten times), who knows almost nothing about good design (or at least is not aware of it), could I learn TDD and good design at the same time? Is it enough to repeat kata? The expert guide would always be desirable, but if it were not there?
|
Can someone learn TDD and good design without on-hands expert guidance? Yes, that is the route I followed. I had been a programmer for 15 years before I became interested in TDD and good design. I learned mostly from reading books, doing kata's, and applying it in practice where I could. -RW
Op 31 juli 2020 om 10:25 schreef Matteo Regazzi <mregazzi@...>:
This week there have been two interesting TDD webinars about why after 20 years it doesn't dominate the software development scene. To tell the truth, in some situations, it is even an unknown technique and therefore not adopted not by choice but out of ignorance.
My personal feeling (I have been in the software development field since 1995 and met extreme programming in 2001) is that in the last 20 years, starting from the rise of agile methodologies, there has been a clear bifurcation: on the one hand, craftmanship, extreme programming, people who apply to their profession that continuous improvement we preach. On the other hand, people who have learned from their predecessors (someone like me, possible), perhaps losing something, as if the transition between anticipatory and evolutionary design had been missing. We missed the design at all. Now my question is: how can we recover? It looks like a chicken egg problem. In the past a programmer learned design principles and techniques and then applied them (with all the disadvantages we know) but the process was clear and straightforward. Today if I started from scratch, under expert guidance, I would probably learn to program and design using TDD. But if I am already a programmer, maybe for 10 years (iterating the same bad year ten times), who knows almost nothing about good design (or at least is not aware of it), could I learn TDD and good design at the same time? Is it enough to repeat kata? The expert guide would always be desirable, but if it were not there?
|
It's really going to depend on what ecosystem you are working in and what tools you'll have available.
I worked for one year in C# on the windows phone. The only thing I was able to take from that year was some lessons in Microsoft sponsorships and a huge leap in what I expect tools to be able to do. I used resharper and typemocks and it allowed me to practice TDD. I was also learning the language, so the psychological barriers were lower.?? After having that experience I was in a better place to judge and improve the tools I use in other ecosystems.
So yes, there is hope, but it's going to take more than just awareness and self study.?
Before working on the windows phone I was working with ActionScript and Flash, and while the culture was supportive, and there were even some tools trying to help, it just wasn't a very good TDD experience. After the windows phone I did work in Unity, and despite being C#, the tools weren't available.
And sometimes, even if the ecosystem exists, it's locked behind a relatively high paywall.
On Fri, 31 Jul 2020, 11:39 Matteo Regazzi, < mregazzi@...> wrote: This week there have been two interesting TDD webinars about why after 20 years it doesn't dominate the software development scene. To tell the truth, in some situations, it is even an unknown technique and therefore not adopted not by choice but out of ignorance.
My personal feeling (I have been in the software development field since 1995 and met extreme programming in 2001) is that in the last 20 years, starting from the rise of agile methodologies, there has been a clear bifurcation: on the one hand, craftmanship, extreme programming, people who apply to their profession that continuous improvement we preach. On the other hand, people who have learned from their predecessors (someone like me, possible), perhaps losing something, as if the transition between anticipatory and evolutionary design had been missing. We missed the design at all. Now my question is: how can we recover? It looks like a chicken egg problem. In the past a programmer learned design principles and techniques and then applied them (with all the disadvantages we know) but the process was clear and straightforward. Today if I started from scratch, under expert guidance, I would probably learn to program and design using TDD. But if I am already a programmer, maybe for 10 years (iterating the same bad year ten times), who knows almost nothing about good design (or at least is not aware of it), could I learn TDD and good design at the same time? Is it enough to repeat kata? The expert guide would always be desirable, but if it were not there?
|
I have started coding back in September 1994, at that time we had no Internet connection in my home country so we could not download and install anything via internet as it is nowadays.
So, I have started coding with QBasic, at that time there was no TDD, BDD anything else. So, far I have worked only with JUnit especially with Spring Framework, Spring Boot Applications.
?
Mit freundlichen Grü?e / Kind regards
?
Ahmet Murati
Email/Skype:
ahmet.murati@...;
amurati
E-Mail/Hangouts?:
ahmetmurati@...
De-Email?: ahmet.murati.1@...
Cellphone/Handy:
+49 1512 3015776
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Avi Kessner
Sent: Friday, 31 July 2020 12:22
To: [email protected]
Subject: Re: [testdrivendevelopment] How to learn good design using TDD ?
?
It's really going to depend on what ecosystem you are working in and what tools you'll have available.
I worked for one year in C# on the windows phone. The only thing I was able to take from that year was some lessons in Microsoft sponsorships and a huge leap in what I expect tools to be able to do. I used resharper and
typemocks and it allowed me to practice TDD. I was also learning the language, so the psychological barriers were lower.??
After having that experience I was in a better place to judge and improve the tools I use in other ecosystems.
So yes, there is hope, but it's going to take more than just awareness and self study.?
Before working on the windows phone I was working with ActionScript and Flash, and while the culture was supportive, and there were even some tools trying to help, it just wasn't a very good TDD experience. After the
windows phone I did work in Unity, and despite being C#, the tools weren't available.
And sometimes, even if the ecosystem exists, it's locked behind a relatively high paywall.
?
On Fri, 31 Jul 2020, 11:39 Matteo Regazzi, <mregazzi@...> wrote:
This week there have been two interesting TDD webinars about why after 20 years it doesn't dominate the software development scene. To tell the truth, in some situations, it is even an unknown technique and therefore
not adopted not by choice but out of ignorance.
My personal feeling (I have been in the software development field since 1995 and met extreme programming in 2001) is that in the last 20 years, starting from the rise of agile methodologies, there has been a clear bifurcation: on the one hand, craftmanship,
extreme programming, people who apply to their profession that continuous improvement we preach. On the other hand, people who have learned from their predecessors (someone like me, possible), perhaps losing something, as if the transition between anticipatory
and evolutionary design had been missing. We missed the design at all. Now my question is: how can we recover? It looks like a chicken egg problem. In the past a programmer learned design principles and techniques and then applied them (with all the disadvantages
we know) but the process was clear and straightforward. Today if I started from scratch, under expert guidance, I would probably learn to program and design using TDD. But if I am already a programmer, maybe for 10 years (iterating the same bad year ten times),
who knows almost nothing about good design (or at least is not aware of it), could I learn TDD and good design at the same time? Is it enough to repeat kata? The expert guide would always be desirable, but if it were not there?
|
could I learn TDD and good design at the same time? Is it enough to repeat kata? The expert guide would always be desirable, but if it were not there?
Yes, the authors of those books we read didn't have those books.?
I started coding without email and the internet. I wasted a lot of time pursuing the objects model things misunderstanding after what I thought was getting on the OOP bandwagon. Up until early this year, I worked alone and didn't attend many events or conferences so I read books and poked around online but only when I had a problem to solve or something new I needed to learn.?
I came to see a problem with my long lived projects eventually becoming difficult and dangerous to change. Most of my projects had a small group of in-house users so they were willing to put up with a lot but as I began writing production code that shipped to customers with machinery, this became a problem.?
I recognized this as a design problem. It took way too long for me to gain an understanding of objects modeling behaviors and not things. I credit Bob Martin's Agile Principles, Patterns, and Practices in C# book for this.?
That led to me finally reading the Refactoring book which led me first understanding the purpose and value of Automated Testing which led to me wanting to learn TDD.
Over time I started going to events, reading even more, and hiring consultants for personal training... I highly recommend J.B. Rainsberger :-)
Since I hired somebody for the first time this year, I started that person off with introducing them to these resources and allowing time for learning and showing that I value continuous improvement in myself and in them.?
All of this was driven by a problem I needed to solve and looking for answers slowly until I learned how to identify and work with quality mentors.?
|
@Avi Kessner Interesting point I think,, what do you mean with you were learning language (I think you are referring to C#) and lower psychological barriers ?
|
I find a common issue with learning TDD and design is that things which used to feel fast now feel much slower, especially as you confront your ignorance. When you are already trying to use a new language, everything feels slower, and you are constantly confronting your ignorance anyways,?so TDD didn't feel like a hurdle. brought to you by the letters A, V, and I
and the number 47
On Fri, Jul 31, 2020 at 4:33 PM Matteo Regazzi < mregazzi@...> wrote: [Edited Message Follows]
@Avi Kessner Interesting point I think,, what do you mean with you were learning language (I think you are referring to C#) and lower psychological barriers ?
|
I think that repeating katas is very good but it's not enough.? The prerequisite is a desire to learn and a dissatisfaction with our current level of knowledge and skill.? If we have these, then there are many additional resources: instructional videos, both free and for-pay, mailing lists such as this one, communities, meetups.
?
I think that learning about "good design" is challenging, because there's no single good, operative definition. There's so much opinion and so little established?facts; even the best books (such as the GoF) are not really based on uncontroversial evidence: the burden of understanding when and why a pattern or a principle is useful stays with the reader.? But I think that by reading, questioning, thinking, discussing and experimenting we can improve quite a lot.
?
I think that we have to live with the fact that all we have about design is principles and heuristics.? In the end the proof of the goodness of a design is in looking at the result: is it easy to change?? Is it easy to understand?? Observation of the quality of the end result trumps any design theory or principle.
?
|
Yes, good design is subjective and conditional.?An analogy to a wise saying would be the observation that the enemy of good design is perfect design.
It is very hard to question your own ideas.? Pair programming accelerates questioning and learning for both parties.? My best advice is to find a similarly motivated development partner.
On Fri, Jul 31, 2020 at 8:40 AM Matteo Vaccari < vaccari@...> wrote: I think that repeating katas is very good but it's not enough.? The prerequisite is a desire to learn and a dissatisfaction with our current level of knowledge and skill.? If we have these, then there are many additional resources: instructional videos, both free and for-pay, mailing lists such as this one, communities, meetups.
?
I think that learning about "good design" is challenging, because there's no single good, operative definition. There's so much opinion and so little established?facts; even the best books (such as the GoF) are not really based on uncontroversial evidence: the burden of understanding when and why a pattern or a principle is useful stays with the reader.? But I think that by reading, questioning, thinking, discussing and experimenting we can improve quite a lot.
?
I think that we have to live with the fact that all we have about design is principles and heuristics.? In the end the proof of the goodness of a design is in looking at the result: is it easy to change?? Is it easy to understand?? Observation of the quality of the end result trumps any design theory or principle.
?
|
First the 4 rules of simple design by Corey Haines:
1. Tests Pass
2. Expresses Intent
3. No Duplication (DRY)
4. Small
I think it's a good starting point when you talk about design.
Then to try to answer your question: how we can recover ?
I may have a lead in the way we learn programming languages, to take some good habits. If you see a PL as a product, when you read the documentation/book on a it, you'll see a lot of assertions about the language features.
The way I learn/teach a language is by testing these features, and I think it's a good seed to move to TDD/BDD.
ex. Assertions: The language X is a static | dynamic strong | weak typed language.
Just with this sentence you have a dozen of tests, you'll experience:
- how to write a test and make it pass
- how to express intent by cuting a sentence in small tests
- duplication or redundancy in the documentation which may emphasize some code smell
- small: each test should contain a single assertion, so you may take the habit to reduce features size in something testable and small
You'll learn with this precise exemple the differents types of the language and their behaviour while converted to others types, some intrisic characterisitics of the PL...
?
1 - Some may think that we're testing implementation. It may be true the border is thin, that's why I would focus on the PL as a product that fill your needs as a user and would prefer given/when/then or rspec (describe/context...) semantic when available (and eventually expressing your needs with user stories if it's not clear).
2 - Some may reproach it's testing after, and it's true, I don't consider it's TDD/BDD of course but just a mean to acquire knowledge about a PL and habits to eventually practice TDD/BDD later. I see similarities with writing documentation (test are documentation).
?
I don't think it's bullet proof to learn good design, and it should be completed by dojo/exercises (ex. object calisthenics), pair and ensemble programming, conference talks, books reading and social sharing... essentially conversations.
What do you think ?
?
|
@Gregory Salvam, Since I read the "Agile Java" book by Jeff Langr, I thought that using TDD to learn a programming language was very useful and I used it both for myself and for teaching. However, I had not thought of applying this concept in the way you expressed it, that is, using the 4 rules of simple design (by Beck :-) even if I better understood them reading Corey Haines) to test the assertions contained in the language manual. It seems to me a very interesting approach that I will try to apply as soon as I have the opportunity/need. Thank you!
|
please note that although Corey has written a nice little book about them, the four rules were originated by Kent Beck.
r sent from iPad, probably via Mars. Errors, if any, are not mine. ronjeffries@... is a better address for me, maybe.
toggle quoted message
Show quoted text
On Aug 6, 2020, at 10:25 AM, Matteo Regazzi <mregazzi@...> wrote:
?@Gregory Salvam, Since I read the "Agile Java" book by Jeff Langr, I thought that using TDD to learn a programming language was very useful and I used it both for myself and for teaching. However, I had not thought of applying this concept in the way you expressed it, that is, using the 4 rules of simple design (by Beck :-) even if I better understood them reading Corey Haines) to test the assertions contained in the language manual. It seems to me a very interesting approach that I will try to apply as soon as I have the opportunity/need. Thank you!
|
I feel I must again point out that "expresses intent" has too low a bar when judged?by the author.? Each additional set of eyes making that judgment improves that standard significantly.
please note that although Corey has written a nice little book about them, the four rules were originated by Kent Beck.
r sent from iPad, probably via Mars. Errors, if any, are not mine. On Aug 6, 2020, at 10:25 AM, Matteo Regazzi <mregazzi@...> wrote:
?@Gregory Salvam, Since I read the "Agile Java" book by Jeff Langr, I thought that using TDD to learn a programming language was very useful and I used it both for myself and for teaching. However, I had not thought of applying this concept in the way you expressed it, that is, using the 4 rules of simple design (by Beck :-) even if I better understood them reading Corey Haines) to test the assertions contained in the language manual. It seems to me a very interesting approach that I will try to apply as soon as I have the opportunity/need. Thank you!
|
Thanks Matteo,
It's still how I prefer to learn about a new language, or new language
feature--each test is an exploration. As far as also using such
"language characterization tests" to also explore simple design rules,
I'd be curious to see some examples of that, Gregory.
I will at times test-drive a small behavioral concept, then see how many
different ways I can achieve that using different language
constructs--primarily to find the one that seems most expressive.
BTW if I ever get my head above water: I've been considering a new
version of Agile Java for years (I still get regular requests for that).
I wrote it only at the point
where I thought Java had made a significant leap in expressiveness with
v5. As much as I'd prefer to work in other languages, I keep getting
pulled back into Java, and it has also gotten to a decent point (though
it's still way too much work in many cases) that it'd be worth another
update. I'd probably be seeking a co-writer, hint. Maybe in 2021?
Cheers,
Jeff
|
| Jeff Langr / Langr Software
Solutions, Inc.?????
|
| ?+1-719-287-4335
|
|
|
|
Matteo Regazzi wrote on 8/6/20 8:25 AM:
toggle quoted message
Show quoted text
@Gregory Salvam, Since I read the "Agile Java" book by Jeff Langr, I
thought that using TDD to learn a programming language was very useful
and I used it both for myself and for teaching. However, I had not
thought of applying this concept in the way you expressed it, that is,
using the 4 rules of simple design (by Beck :-) even if I better
understood them reading Corey Haines) to test the assertions contained
in the language manual. It seems to me a very interesting approach that I
will try to apply as soon as I have the opportunity/need. Thank you!
_._,_._,_
|
Currently, I am learning Java 11
Mit freundlichen Grü?e / Kind regards
?
Ahmet Murati
Email/Skype:?ahmet.murati@...;?amurati
E-Mail/Hangouts :?ahmetmurati@...
De-Email :?ahmet.murati.1@...
Cellphone/Handy:?+49 1512 3015776
toggle quoted message
Show quoted text
Thanks Matteo,
It's still how I prefer to learn about a new language, or new language feature--each test is an exploration. As far as also using such "language characterization tests" to also explore simple design rules, I'd be curious to see some examples of that, Gregory.
I will at times test-drive a small behavioral concept, then see how many different ways I can achieve that using different language constructs--primarily to find the one that seems most expressive.
BTW if I ever get my head above water: I've been considering a new version of Agile Java for years (I still get regular requests for that). I wrote it
only at the point where I thought Java had made a significant leap in expressiveness with v5. As much as I'd prefer to work in other languages, I keep getting pulled back into Java, and it has also gotten to a decent point
(though it's still way too much work in many cases) that it'd be worth another update. I'd probably be seeking a co-writer, hint. Maybe in 2021?
Cheers,
Jeff
|
|
Jeff Langr / Langr Software Solutions, Inc.?????
|
| ?+1-719-287-4335
|
|
|
|
Matteo Regazzi wrote on 8/6/20 8:25 AM:
@Gregory Salvam, Since I read the "Agile Java" book by Jeff Langr, I thought that using TDD to learn a programming language was very useful and I used it both for myself and for teaching. However, I had not thought of applying this concept
in the way you expressed it, that is, using the 4 rules of simple design (by Beck :-) even if I better understood them reading Corey Haines) to test the assertions contained in the language manual. It seems to me a very interesting approach that I will try
to apply as soon as I have the opportunity/need. Thank you!
|
On the subject of learning a language via TDD: of related interest is that for many languages you can find "<Language name> Koans", where someone has already written a suite of failing unit tests of language features, complete with helpful error messages that allow you to get the tests passing. I first learned of it via??which I believe to be the original, but it's easy enough to Google e.g. "Java Koans" and find something like?.
Returning to the OP, I think it's worth pointing out that?improving the design of your code is one motivation for TDD. So it should be possible to study the two in parallel.?Moreover, the fact that in TDD your tests serve a dual purpose- acting as API design as well as regression safety- in some cases causes a tension between these competing requirements. The "London" (or "outside-in"/"top-down") approach to TDD differs from the "Chicago" ("inside-out"/ "bottom-up") approach largely due to the role played by test doubles, which are introduced to aid design at the cost of increasing the risk of false positives/negatives in tests for the correctness of your code. (?is a good free resource to read more about this stuff.)?
Cheers,
Rob
|
A few months ago, I used TDD to learn some Kotlin basics. While I could make Green code, I needed help with the Refactor step. It came in two forms:
? The IDE itself offered suggestions. ? Viewers on Twitch wrote comments as I was coding.
Both are forms of community knowledge. The first set is encoded in a tool. The second set came from mobbing/ensemble programming.
 |
Jon Reid
Quality Coding, Inc.
|
|
Thanks for the correction, and sorry for not crediting Kent Beck. I like the point Jeff made, by refactoring your code you can also try different solutions "to find the one that seems most expressive", this is definitely tied to design.
While I was writing the first message, I was wondering if there's some previous work on this subject and immediately thought to Apprenticeship Patterns by David H. Hoover and Adewale Oshineye.
(I dug a bit and found also Pragmatic thinking and learning by Andy Hunt, which I've not read, sorry)
In apprenticeship patterns thre's 3 related patterns:
?- "create feedback loop": TDD is cited (personally I've also used metrics like cyclomatic complexity to get feedback, it can temporarily help)
- "breakable toy" and "practice, practice, and practice" which are linked to TDD by the safety environment it provides to experiment and gain confidence in our work.
Also increasing the number of assessment as an impact on retention (cf. ) and all these patterns are kind of assessments, they help to form "many associations with other things in the mind".
I've tested this approach with a group of people who had never programmed (it was in JS with jasmine, 10 years ago). I first made a short language introduction (1~2h) with a lot of assertions and right after continued with a randori where we tested all. It worked well, beyond my expectations. I made another experiment when I started to learn elixir, by sharing a pimped version of my own learning support (which I falsely called koans).
Aftermaths I believe it should be something more personal because nobody can do the job to memorize for you .
Even if Koans are great, they make you follow someone else's path which tends to give answers before you have the time to ask yourself the questions, it's a bit less efficient. (see Stephen Downes on personalized vs personal learning)
On the subject of learning a language via TDD: of related interest is that for many languages you can find "<Language name> Koans", where someone has already written a suite of failing unit tests of language features, complete with helpful error messages that allow you to get the tests passing. I first learned of it via??which I believe to be the original, but it's easy enough to Google e.g. "Java Koans" and find something like?.
Returning to the OP, I think it's worth pointing out that?improving the design of your code is one motivation for TDD. So it should be possible to study the two in parallel.?Moreover, the fact that in TDD your tests serve a dual purpose- acting as API design as well as regression safety- in some cases causes a tension between these competing requirements. The "London" (or "outside-in"/"top-down") approach to TDD differs from the "Chicago" ("inside-out"/ "bottom-up") approach largely due to the role played by test doubles, which are introduced to aid design at the cost of increasing the risk of false positives/negatives in tests for the correctness of your code. (?is a good free resource to read more about this stuff.)?
Cheers,
Rob
|
Matteo Regazzi
John Welty
Gregory Salvan