Which comes first: design skill or TDD?

On Wed, Jul 5, 2023 at 2:39?PM Sleepyfox <sleepyfox@...> wrote:

?

But TDD doesn't teach you about coupling and cohesion, it doesn't teach you about 'clean code' (whatever you determine that to mean), it doesn't even teach you about removal of duplication - that's Simple Design.

I don't think I've ever encountered exactly this point before. To the extent that it's true, I find it useless. :) Even so, I appreciate its attempt to be precise and to highlight the potential for confusion due to differences in understanding of terms.

I claim that practising TDD guides one to learn these things, because one can't _drive_ one's development using tests while ignoring what happens in the mind when you try. :) One thing that happens: one gets bored from typing the same thing over and over again and seeks a way to reduce the effort, which seems quite likely to at least encourage managing duplication somehow. If not, then what could possibly be happening during the "refactor" step?

A hypothetical programmer who is entirely unmoved by seeing duplication, who seems content literally to duplicate code all day long, is perhaps not refactoring, and therefore couldn't practise TDD.

This leads me, however, to wonder idly about what refactoring looks like if we use principles other than the Four Elements of Simple Design to inform our refactoring choices. I don't think I'm capable of imagining how that would actually happen, even though I can imagine that it's theoretically possible. I suppose someone who wanted to refactor, but didn't know those things, would be forced to find them, and therefore TDD would be the trigger for learning those things.

--

J. B. (Joe) Rainsberger :: ?:: ::

Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.

--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002

#36249

One thing that helped me with design by using TDD was how it encourages making constant changes to the code. It makes changes necessary because you haven't thought too far ahead, and it makes changes safe because of the quality of the tests and how fast you can run them. Because you are constantly changing the code, this leads to wanting to find ways to make those changes easier, and code that is easy and safe to change strongly overlaps with well-designed code. Reducing coupling and increasing cohesion is one of those things that you find makes code easier to change.

On Wednesday, July 19, 2023 at 09:34:33 AM EDT, J. B. Rainsberger <me@...> wrote:

On Wed, Jul 5, 2023 at 2:39?PM Sleepyfox <sleepyfox@...> wrote:

?

But TDD doesn't teach you about coupling and cohesion, it doesn't teach you about 'clean code' (whatever you determine that to mean), it doesn't even teach you about removal of duplication - that's Simple Design.

I don't think I've ever encountered exactly this point before. To the extent that it's true, I find it useless. :) Even so, I appreciate its attempt to be precise and to highlight the potential for confusion due to differences in understanding of terms.

I claim that practising TDD guides one to learn these things, because one can't _drive_ one's development using tests while ignoring what happens in the mind when you try. :) One thing that happens: one gets bored from typing the same thing over and over again and seeks a way to reduce the effort, which seems quite likely to at least encourage managing duplication somehow. If not, then what could possibly be happening during the "refactor" step?

A hypothetical programmer who is entirely unmoved by seeing duplication, who seems content literally to duplicate code all day long, is perhaps not refactoring, and therefore couldn't practise TDD.

This leads me, however, to wonder idly about what refactoring looks like if we use principles other than the Four Elements of Simple Design to inform our refactoring choices. I don't think I'm capable of imagining how that would actually happen, even though I can imagine that it's theoretically possible. I suppose someone who wanted to refactor, but didn't know those things, would be forced to find them, and therefore TDD would be the trigger for learning those things.

--

J. B. (Joe) Rainsberger :: ?:: ::

Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.

--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002

#36260

On Wed, Jul 19, 2023 at 3:55?PM Vaughn Cato via <vaughn_cato=[email protected]> wrote:

?

One thing that helped me with design by using TDD was how it encourages making constant changes to the code. It makes changes necessary because you haven't thought too far ahead, and it makes changes safe because of the quality of the tests and how fast you can run them. Because you are constantly changing the code, this leads to wanting to find ways to make those changes easier, and code that is easy and safe to change strongly overlaps with well-designed code. Reducing coupling and increasing cohesion is one of those things that you find makes code easier to change.

This is perhaps one aspect of Evolutionary Design in general that I emphasize: it normalizes changing code; it helps reverse the belief that changing code is a failure of prediction and that there is a "first time" to "get it right".

I recently sidestepped an argument on Reddit about this. It had been a long time since I'd encountered someone who genuinely believed that one must always get the design right the first time and every other way to work is wrong. They framed it as something like "Why would you waste time building it the wrong way just so that you can build it the right way later?!" They seemed unable to see that it might not be possible to see "the right way" and "the wrong way" in advance or that those labels might change or that those labels are not helpful in the first place.

I don't know where people are learning this, apart from generic "life lessons" of perfectionism drilled into them when they were very young.

--

J. B. (Joe) Rainsberger :: ?:: ::

Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.

--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002

#36272

On 7/26/23 9:25 AM, J. B. Rainsberger wrote:
On Wed, Jul 19, 2023 at 3:55?PM Vaughn Cato via groups.io <> <vaughn_cato@... <mailto:[email protected]>> wrote:
One thing that helped me with design by using TDD was how it
    encourages making constant changes to the code. It makes changes
    necessary because you haven't thought too far ahead, and it makes
    changes safe because of the quality of the tests and how fast you
    can run them. Because you are constantly changing the code, this
    leads to wanting to find ways to make those changes easier, and code
    that is easy and safe to change strongly overlaps with well-designed
    code. Reducing coupling and increasing cohesion is one of those
    things that you find makes code easier to change.
This is perhaps one aspect of Evolutionary Design in general that I emphasize: it normalizes changing code; it helps reverse the belief that changing code is a failure of prediction and that there is a "first time" to "get it right".
I recently sidestepped an argument on Reddit about this. It had been a long time since I'd encountered someone who genuinely believed that one must always get the design right the first time and every other way to work is wrong. They framed it as something like "Why would you waste time building it the wrong way just so that you can build it the right way later?!" They seemed unable to see that it might not be possible to see "the right way" and "the wrong way" in advance or that those labels might change or that those labels are not helpful in the first place.
I don't know where people are learning this, apart from generic "life lessons" of perfectionism drilled into them when they were very young.A lot of traditional approaches treat any need to change the code as evidence of a defect. Back around the start of the century, someone told me they were following Watts Humphrey's Personal Software Process (PSP) and were counting every time they hit the backspace key as a defect they had corrected.

 - George

-- 
 ----------------------------------------------------------------------
  * George Dinwiddie *                      
  Software Development                    
  Consultant and Coach         
 ----------------------------------------------------------------------

#36274

"I don't know where people are learning this, apart from generic "life lessons" of perfectionism drilled into them when they were very young."

I left university teaching about 15 years ago, but I always had to fight the old guard of every faculty I worked for on that issue for every programming class I ever taught.? Even the ones who did understand?my points said it was too hard for students to learn good software design without having them do a good design for fixed assignment requirements before writing any code (like making students turn in an outline before writing their papers).? Even if we grant that premise (which I do not), waterfall just being an artifact of teaching skills in isolation gets ingrained as to how to develop software.

Show quoted text

On Wed, Jul 26, 2023 at 9:08?AM George Dinwiddie <lists@...> wrote:

On 7/26/23 9:25 AM, J. B. Rainsberger wrote:
> On Wed, Jul 19, 2023 at 3:55?PM Vaughn Cato via
> <> <vaughn_cato=[email protected]
> <mailto:[email protected]>> wrote:
>
>? ? ?One thing that helped me with design by using TDD was how it
>? ? ?encourages making constant changes to the code. It makes changes
>? ? ?necessary because you haven't thought too far ahead, and it makes
>? ? ?changes safe because of the quality of the tests and how fast you
>? ? ?can run them. Because you are constantly changing the code, this
>? ? ?leads to wanting to find ways to make those changes easier, and code
>? ? ?that is easy and safe to change strongly overlaps with well-designed
>? ? ?code. Reducing coupling and increasing cohesion is one of those
>? ? ?things that you find makes code easier to change.
>
>
> This is perhaps one aspect of Evolutionary Design in general that I
> emphasize: it normalizes changing code; it helps reverse the belief that
> changing code is a failure of prediction and that there is a "first
> time" to "get it right".
>
> I recently sidestepped an argument on Reddit about this. It had been a
> long time since I'd encountered someone who genuinely believed that one
> must always get the design right the first time and every other way to
> work is wrong. They framed it as something like "Why would you waste
> time building it the wrong way just so that you can build it the right
> way later?!" They seemed unable to see that it might not be possible to
> see "the right way" and "the wrong way" in advance or that those labels
> might change or that those labels are not helpful in the first place.
>
> I don't know where people are learning this, apart from generic "life
> lessons" of perfectionism drilled into them when they were very young.

A lot of traditional approaches treat any need to change the code as
evidence of a defect. Back around the start of the century, someone told
me they were following Watts Humphrey's Personal Software Process (PSP)
and were counting every time they hit the backspace key as a defect they
had corrected.

? - George

--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------

开云体育

Which comes first: design skill or TDD?