What has changed for you over the past 20 years?


J. B. Rainsberger
 

On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


Jay Bazuzi
 

From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


George Paci
 

(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


Slava Imeshev <imeshev@...>
 

George, thank you for raising the discussion to the top level.

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

7. Code reviews now must which is great.

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

Slava

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:


(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


R Dymond
 

My first Agile project was in 2002, so not 20 years, however that first project we started with TDD, CC.net and monthly releases.

Since that time I have seen XP go from early adopter "awesome" to neglected stepchild of Scrum, to somewhat mysterious/intriguing ghost of development gurus past.

Reading Kent's posts from facebookland or some of the senior google alum I follow (ie Jeff Nelson chromebook inventor), it seems among these non XP practicing smart engineers Agile developer skills aren't considered necessary or required. That to me is sad though not unexpected. Developers have as much difficulty changing their habits as anyone else. Besides, we're too busy.

At a recent client that has success adopting Agile in their hardware manufacturing group, their software group remains a flailing mess, the current S/W project running millions over budget (waterfall) and the CTO recently fired for it. That CTO connected me with that S/W group before the sh*t show got rolling but they declined my services. 

That same fired CTO sponsored agile in 5 pilots, all hardware, and all delivering. In those pilots we emphasize less welding and more (overbuilt) interfaces (mostly ignored because if cost) more modularity, more standardization, and TDD thinking, which translates into hypothesis to test rig and interface, then design to pass. These are not quite unit tests, but somewhere between unit and functional tests. Selling these ideas in mechanical engineering teams today is like selling OO in the 90s. Some get it and love it, others don't care, and most are sorta neutral. 

By decoupling and enabling reuse we decrease the amount of engineering labour required to build new H/W systems. Many engineers do not think this is a good idea, since they're paid for every hour of engineering required ("and we're going to engineer the sh*t outa this thing"). Similarly, sales of standardized parts generate less profit then sales of specialized parts.  Case in point, try to mount wheels for a bmw on a similar sized sedan from another manufacturer. There are dozens bolt patterns to hold a wheel on a car, the reason for so many has to do with profit, not passing the test of holding a wheel on.

Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

To end on a more positive note, tool support has never been better!

Cheers Robin.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond


On Tue, Dec 3, 2019, 12:42 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
George, thank you for raising the discussion to the top level.

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

7. Code reviews now must which is great.

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

Slava

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:


(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


Slava Imeshev <imeshev@...>
 

Robin, this is good stuff. Is it possible that XP was stopped being promoted as a practice before it became a household name? Books were written, speeches given and then framing fathers went their ways? If you look at Scrum, the picture is quite different. Maybe it's time to make XP a system?

Slava

On Tuesday, December 3, 2019, 9:58:03 PM PST, R Dymond <rdymond@...> wrote:


My first Agile project was in 2002, so not 20 years, however that first project we started with TDD, CC.net and monthly releases.

Since that time I have seen XP go from early adopter "awesome" to neglected stepchild of Scrum, to somewhat mysterious/intriguing ghost of development gurus past.

Reading Kent's posts from facebookland or some of the senior google alum I follow (ie Jeff Nelson chromebook inventor), it seems among these non XP practicing smart engineers Agile developer skills aren't considered necessary or required. That to me is sad though not unexpected. Developers have as much difficulty changing their habits as anyone else. Besides, we're too busy.

At a recent client that has success adopting Agile in their hardware manufacturing group, their software group remains a flailing mess, the current S/W project running millions over budget (waterfall) and the CTO recently fired for it. That CTO connected me with that S/W group before the sh*t show got rolling but they declined my services. 

That same fired CTO sponsored agile in 5 pilots, all hardware, and all delivering. In those pilots we emphasize less welding and more (overbuilt) interfaces (mostly ignored because if cost) more modularity, more standardization, and TDD thinking, which translates into hypothesis to test rig and interface, then design to pass. These are not quite unit tests, but somewhere between unit and functional tests. Selling these ideas in mechanical engineering teams today is like selling OO in the 90s. Some get it and love it, others don't care, and most are sorta neutral. 

By decoupling and enabling reuse we decrease the amount of engineering labour required to build new H/W systems. Many engineers do not think this is a good idea, since they're paid for every hour of engineering required ("and we're going to engineer the sh*t outa this thing"). Similarly, sales of standardized parts generate less profit then sales of specialized parts.  Case in point, try to mount wheels for a bmw on a similar sized sedan from another manufacturer. There are dozens bolt patterns to hold a wheel on a car, the reason for so many has to do with profit, not passing the test of holding a wheel on.

Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

To end on a more positive note, tool support has never been better!

Cheers Robin.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Tue, Dec 3, 2019, 12:42 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
George, thank you for raising the discussion to the top level.

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

7. Code reviews now must which is great.

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

Slava

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:


(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


Steve Gordon
 

Unlike Scrum, nobody owns XP to make it anything.  On the other hand, there is also nobody to stop you from trying.

Given the current state of XP, whatever you might try to make of it would likely benefit from starting with a new name.

On Wed, Dec 4, 2019 at 12:01 AM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin, this is good stuff. Is it possible that XP was stopped being promoted as a practice before it became a household name? Books were written, speeches given and then framing fathers went their ways? If you look at Scrum, the picture is quite different. Maybe it's time to make XP a system?

Slava

On Tuesday, December 3, 2019, 9:58:03 PM PST, R Dymond <rdymond@...> wrote:


My first Agile project was in 2002, so not 20 years, however that first project we started with TDD, CC.net and monthly releases.

Since that time I have seen XP go from early adopter "awesome" to neglected stepchild of Scrum, to somewhat mysterious/intriguing ghost of development gurus past.

Reading Kent's posts from facebookland or some of the senior google alum I follow (ie Jeff Nelson chromebook inventor), it seems among these non XP practicing smart engineers Agile developer skills aren't considered necessary or required. That to me is sad though not unexpected. Developers have as much difficulty changing their habits as anyone else. Besides, we're too busy.

At a recent client that has success adopting Agile in their hardware manufacturing group, their software group remains a flailing mess, the current S/W project running millions over budget (waterfall) and the CTO recently fired for it. That CTO connected me with that S/W group before the sh*t show got rolling but they declined my services. 

That same fired CTO sponsored agile in 5 pilots, all hardware, and all delivering. In those pilots we emphasize less welding and more (overbuilt) interfaces (mostly ignored because if cost) more modularity, more standardization, and TDD thinking, which translates into hypothesis to test rig and interface, then design to pass. These are not quite unit tests, but somewhere between unit and functional tests. Selling these ideas in mechanical engineering teams today is like selling OO in the 90s. Some get it and love it, others don't care, and most are sorta neutral. 

By decoupling and enabling reuse we decrease the amount of engineering labour required to build new H/W systems. Many engineers do not think this is a good idea, since they're paid for every hour of engineering required ("and we're going to engineer the sh*t outa this thing"). Similarly, sales of standardized parts generate less profit then sales of specialized parts.  Case in point, try to mount wheels for a bmw on a similar sized sedan from another manufacturer. There are dozens bolt patterns to hold a wheel on a car, the reason for so many has to do with profit, not passing the test of holding a wheel on.

Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

To end on a more positive note, tool support has never been better!

Cheers Robin.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Tue, Dec 3, 2019, 12:42 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
George, thank you for raising the discussion to the top level.

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

7. Code reviews now must which is great.

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

Slava

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:


(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


R Dymond
 

Why? Probably need 5 or more whys to really understand why.

Why does the Canadian government have a f'd up payroll system that will cost $2.6B to stabilize enough so that they can move off it? Why are the 737Max planes grounded? Why is there so much resistance to doing something as simple as Scrum? Our business continues to be outstanding at failing to deliver products that work and have high quality, why is that?


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 1:00 AM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin, this is good stuff. Is it possible that XP was stopped being promoted as a practice before it became a household name? Books were written, speeches given and then framing fathers went their ways? If you look at Scrum, the picture is quite different. Maybe it's time to make XP a system?

Slava

On Tuesday, December 3, 2019, 9:58:03 PM PST, R Dymond <rdymond@...> wrote:


My first Agile project was in 2002, so not 20 years, however that first project we started with TDD, CC.net and monthly releases.

Since that time I have seen XP go from early adopter "awesome" to neglected stepchild of Scrum, to somewhat mysterious/intriguing ghost of development gurus past.

Reading Kent's posts from facebookland or some of the senior google alum I follow (ie Jeff Nelson chromebook inventor), it seems among these non XP practicing smart engineers Agile developer skills aren't considered necessary or required. That to me is sad though not unexpected. Developers have as much difficulty changing their habits as anyone else. Besides, we're too busy.

At a recent client that has success adopting Agile in their hardware manufacturing group, their software group remains a flailing mess, the current S/W project running millions over budget (waterfall) and the CTO recently fired for it. That CTO connected me with that S/W group before the sh*t show got rolling but they declined my services. 

That same fired CTO sponsored agile in 5 pilots, all hardware, and all delivering. In those pilots we emphasize less welding and more (overbuilt) interfaces (mostly ignored because if cost) more modularity, more standardization, and TDD thinking, which translates into hypothesis to test rig and interface, then design to pass. These are not quite unit tests, but somewhere between unit and functional tests. Selling these ideas in mechanical engineering teams today is like selling OO in the 90s. Some get it and love it, others don't care, and most are sorta neutral. 

By decoupling and enabling reuse we decrease the amount of engineering labour required to build new H/W systems. Many engineers do not think this is a good idea, since they're paid for every hour of engineering required ("and we're going to engineer the sh*t outa this thing"). Similarly, sales of standardized parts generate less profit then sales of specialized parts.  Case in point, try to mount wheels for a bmw on a similar sized sedan from another manufacturer. There are dozens bolt patterns to hold a wheel on a car, the reason for so many has to do with profit, not passing the test of holding a wheel on.

Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

To end on a more positive note, tool support has never been better!

Cheers Robin.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Tue, Dec 3, 2019, 12:42 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
George, thank you for raising the discussion to the top level.

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

7. Code reviews now must which is great.

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

Slava

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:


(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


Steve Gordon
 

The hubris of the people in charge is one thing that has not changed in the past 20 years.  We asked this same question 20 years ago, and will be 20 years from now, too.

Face it, software development is primarily a people problem - not just the people developing the software, but also the customers, subject matter experts, managers and ultimate decision makers.  Scrum and XP works well, is large part because they provide more compensation for human error, but they do not address the natural resistance of those in control losing some of that control.  

The emergence of SAFe (which in practice kills agility by ceding control to people who are neither developing nor consuming the software) is prime evidence the human resistance to maintain the status quo is the answer to these 5 whys.


On Wed, Dec 4, 2019 at 6:16 AM R Dymond <rdymond@...> wrote:
Why? Probably need 5 or more whys to really understand why.

Why does the Canadian government have a f'd up payroll system that will cost $2.6B to stabilize enough so that they can move off it? Why are the 737Max planes grounded? Why is there so much resistance to doing something as simple as Scrum? Our business continues to be outstanding at failing to deliver products that work and have high quality, why is that?  


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond



Ron Jeffries
 

Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@acm.org is a better address for me, maybe.

On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@innovel.net> wrote:

Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP, not Scrum for great ideas on how to make great quality software.
I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.

I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.
It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R


R Dymond
 

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond


On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
>
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
>
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
>
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R




Chet Hendrickson
 

Hi,

Ron and I have often talked about the name, Extreme Programming, disappearing as it turned into just the way we build software.  It is clear that that is reality in many places and the exact opposite in others.

chet
Chet Hendrickson

On Dec 4, 2019, at 1:42 PM, R Dymond <rdymond@...> wrote:

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
> 
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
> 
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
> 
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R





Slava Imeshev <imeshev@...>
 

We can do 5 Whys. 

On Dec 4, 2019, at 5:16 AM, R Dymond <rdymond@...> wrote:

Why? Probably need 5 or more whys to really understand why.

Why does the Canadian government have a f'd up payroll system that will cost $2.6B to stabilize enough so that they can move off it? Why are the 737Max planes grounded? Why is there so much resistance to doing something as simple as Scrum? Our business continues to be outstanding at failing to deliver products that work and have high quality, why is that?


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 1:00 AM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin, this is good stuff. Is it possible that XP was stopped being promoted as a practice before it became a household name? Books were written, speeches given and then framing fathers went their ways? If you look at Scrum, the picture is quite different. Maybe it's time to make XP a system?

Slava

On Tuesday, December 3, 2019, 9:58:03 PM PST, R Dymond <rdymond@...> wrote:


My first Agile project was in 2002, so not 20 years, however that first project we started with TDD, CC.net and monthly releases.

Since that time I have seen XP go from early adopter "awesome" to neglected stepchild of Scrum, to somewhat mysterious/intriguing ghost of development gurus past.

Reading Kent's posts from facebookland or some of the senior google alum I follow (ie Jeff Nelson chromebook inventor), it seems among these non XP practicing smart engineers Agile developer skills aren't considered necessary or required. That to me is sad though not unexpected. Developers have as much difficulty changing their habits as anyone else. Besides, we're too busy.

At a recent client that has success adopting Agile in their hardware manufacturing group, their software group remains a flailing mess, the current S/W project running millions over budget (waterfall) and the CTO recently fired for it. That CTO connected me with that S/W group before the sh*t show got rolling but they declined my services. 

That same fired CTO sponsored agile in 5 pilots, all hardware, and all delivering. In those pilots we emphasize less welding and more (overbuilt) interfaces (mostly ignored because if cost) more modularity, more standardization, and TDD thinking, which translates into hypothesis to test rig and interface, then design to pass. These are not quite unit tests, but somewhere between unit and functional tests. Selling these ideas in mechanical engineering teams today is like selling OO in the 90s. Some get it and love it, others don't care, and most are sorta neutral. 

By decoupling and enabling reuse we decrease the amount of engineering labour required to build new H/W systems. Many engineers do not think this is a good idea, since they're paid for every hour of engineering required ("and we're going to engineer the sh*t outa this thing"). Similarly, sales of standardized parts generate less profit then sales of specialized parts.  Case in point, try to mount wheels for a bmw on a similar sized sedan from another manufacturer. There are dozens bolt patterns to hold a wheel on a car, the reason for so many has to do with profit, not passing the test of holding a wheel on.

Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

To end on a more positive note, tool support has never been better!

Cheers Robin.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Tue, Dec 3, 2019, 12:42 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
George, thank you for raising the discussion to the top level.

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

7. Code reviews now must which is great.

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

Slava

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:


(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--




Slava Imeshev <imeshev@...>
 

Robin,

I think it’s a great idea to build a sellable brand for XP. How about 'Effective Programming', as in delivering results?

Slava

On Dec 4, 2019, at 10:42 AM, R Dymond <rdymond@...> wrote:

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
>
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
>
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
>
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R





Daniel Nuñez Carhuayo
 

Hi everybody,

A 5 years ago in my work we was practice TDD on a application with a group of 4 engineers, 2 of them choosed working in one day without writing tests for new features and, effectively they made more features that day but, at next day some features begun to show problems, fix one do damage other features, results: writing test as crazy man's at 3am, next day after wroted tests all are fine again.

I don't say that others Technics not work or are wrong, I say it's important to consider the human skills, people's that can do that and Risk if they can't do, I believe in each engineer but to err is human IMHO

See you,

Daniel Núñez

El mar., 29 de octubre de 2019 9:38 a. m., J. B. Rainsberger <jbrains762@...> escribió:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--


Slava Imeshev <imeshev@...>
 

Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.


On Dec 4, 2019, at 1:23 PM, Daniel Nuñez Carhuayo <danielantonionunez@...> wrote:

Hi everybody,

A 5 years ago in my work we was practice TDD on a application with a group of 4 engineers, 2 of them choosed working in one day without writing tests for new features and, effectively they made more features that day but, at next day some features begun to show problems, fix one do damage other features, results: writing test as crazy man's at 3am, next day after wroted tests all are fine again.

I don't say that others Technics not work or are wrong, I say it's important to consider the human skills, people's that can do that and Risk if they can't do, I believe in each engineer but to err is human IMHO

See you,

Daniel Núñez

El mar., 29 de octubre de 2019 9:38 a. m., J. B. Rainsberger <jbrains762@...> escribió:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--




Mike Bowler
 

Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


John Maxwell
 

On 12/04/2019 04:47:58 PM, Mike Bowler wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any
code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put
in place and the “quality” that results. I expect many of us here have
seen that disaster.
I haven't. What's the failure mechanism?

--
John Maxwell KB3VLL jmax@jmaxhome.com

"Personally I'm fond of using Dedekind cuts for representing the Reals,
but it gets cumbersome to use when balancing one's checkbook."
-Charles Haynes


Mike Bowler
 

We rapidly get a collection of tests that increase code coverage without testing any actual behaviour. I’ve seen whole test setups with few or no assertions.  This is then worse than having low test coverage because we can’t trust any of it.

Then when the team is in the habit of writing garbage tests, that starts to leak into their production code and quality starts dropping there too. They care less about the quality. I expect this is some variant of Social Proof or the Broken Window Effect.

I can’t think of a single case where imposing a high code coverage number on checkin,  up front, has resulted in the team writing better code and I can think of many cases where the reverse is true.

Now, the one case that I have seen work is where the team starts a mandatory code coverage based on where they are today and very gradually increases the mandatory amount over time to slowly improve. Although even that causes problems when new people are brought onto the team or new teams take over that code base.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.

On Dec 4, 2019, at 4:51 PM, John Maxwell <jmax@...> wrote:

On 12/04/2019 04:47:58 PM, Mike Bowler wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any
code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put
in place and the “quality” that results. I expect many of us here have
seen that disaster.

I haven't. What's the failure mechanism?

--
John Maxwell  KB3VLL  jmax@...

"Personally I'm fond of using Dedekind cuts for representing the Reals,
but it gets cumbersome to use when balancing one's checkbook."
       -Charles Haynes




Todd Sedano
 


I prefer not writing unit tests for configuration. If configuration is wrong, then just fix it. I prefer writing unit tests for my control flow. This means that my code will never have 100% unit test coverage. 

As a concrete example, consider an object has a static/fixed hash. (Eg CA => California) or (12 => purchase order)...it’s either right or wrong, no need to write lots of low value tests


On Wed, Dec 4, 2019 at 1:51 PM John Maxwell <jmax@...> wrote:
On 12/04/2019 04:47:58 PM, Mike Bowler wrote:
> > Yep. TDD is a holly grail. Just having a policy not to check in any
> code without 100% unit test coverage does wonders to quality.
>
> I can’t tell if you meant that as sarcasm. I’ve seen that policy put
> in place and the “quality” that results. I expect many of us here have
> seen that disaster.
>
I haven't. What's the failure mechanism?

--
John Maxwell  KB3VLL  jmax@...

"Personally I'm fond of using Dedekind cuts for representing the Reals,
 but it gets cumbersome to use when balancing one's checkbook."
        -Charles Haynes




Slava Imeshev <imeshev@...>
 

Of course we mean good tests. I’m doubtful that it’s possible to claim a good test without good coverage.

Slava

On Dec 4, 2019, at 2:05 PM, Mike Bowler <mbowler@...> wrote:

We rapidly get a collection of tests that increase code coverage without testing any actual behaviour. I’ve seen whole test setups with few or no assertions.  This is then worse than having low test coverage because we can’t trust any of it.

Then when the team is in the habit of writing garbage tests, that starts to leak into their production code and quality starts dropping there too. They care less about the quality. I expect this is some variant of Social Proof or the Broken Window Effect.

I can’t think of a single case where imposing a high code coverage number on checkin,  up front, has resulted in the team writing better code and I can think of many cases where the reverse is true.

Now, the one case that I have seen work is where the team starts a mandatory code coverage based on where they are today and very gradually increases the mandatory amount over time to slowly improve. Although even that causes problems when new people are brought onto the team or new teams take over that code base.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.

On Dec 4, 2019, at 4:51 PM, John Maxwell <jmax@...> wrote:

On 12/04/2019 04:47:58 PM, Mike Bowler wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any
code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put
in place and the “quality” that results. I expect many of us here have
seen that disaster.

I haven't. What's the failure mechanism?

--
John Maxwell  KB3VLL  jmax@...

"Personally I'm fond of using Dedekind cuts for representing the Reals,
but it gets cumbersome to use when balancing one's checkbook."
       -Charles Haynes





Slava Imeshev <imeshev@...>
 

Mike,

I’m not sure what you mean. Requiring 100% unit test coverage works quite well in my experience.

Slava

On Dec 4, 2019, at 1:47 PM, Mike Bowler <mbowler@...> wrote:

Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


Slava Imeshev <imeshev@...>
 

Well, there are cases when writing tests for configurations files still may make sense. An example is typos. I’ve seen my share of bugs where a parameter name or a value were misspelled. Adding a test that reads the config and confirms that parameter is present allows CI to verify that the fix is there and also builds a regression suite that ensures that this doesn’t happen again.


On Dec 4, 2019, at 2:06 PM, Todd Sedano <professor@...> wrote:


I prefer not writing unit tests for configuration. If configuration is wrong, then just fix it. I prefer writing unit tests for my control flow. This means that my code will never have 100% unit test coverage. 

As a concrete example, consider an object has a static/fixed hash. (Eg CA => California) or (12 => purchase order)...it’s either right or wrong, no need to write lots of low value tests

On Wed, Dec 4, 2019 at 1:51 PM John Maxwell <jmax@...> wrote:
On 12/04/2019 04:47:58 PM, Mike Bowler wrote:
> > Yep. TDD is a holly grail. Just having a policy not to check in any
> code without 100% unit test coverage does wonders to quality.
>
> I can’t tell if you meant that as sarcasm. I’ve seen that policy put
> in place and the “quality” that results. I expect many of us here have
> seen that disaster.
>
I haven't. What's the failure mechanism?

--
John Maxwell  KB3VLL  jmax@...

"Personally I'm fond of using Dedekind cuts for representing the Reals,
 but it gets cumbersome to use when balancing one's checkbook."
        -Charles Haynes





Avi Kessner
 

If I were to market XP today I would call it "Continuous Coding". So you do CC, then CI, then CD.  You could shorten this to C3, and bring XP back in a full circle.


On Wed, Dec 4, 2019, 23:22 Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin,

I think it’s a great idea to build a sellable brand for XP. How about 'Effective Programming', as in delivering results?

Slava

On Dec 4, 2019, at 10:42 AM, R Dymond <rdymond@...> wrote:

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
>
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
>
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
>
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R





Jim Shore
 

My experience is the same as Mike’s.


James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com

On Dec 5, 2019, at 9:05 AM, Mike Bowler <mbowler@...> wrote:

We rapidly get a collection of tests that increase code coverage without testing any actual behaviour. I’ve seen whole test setups with few or no assertions.  This is then worse than having low test coverage because we can’t trust any of it.

Then when the team is in the habit of writing garbage tests, that starts to leak into their production code and quality starts dropping there too. They care less about the quality. I expect this is some variant of Social Proof or the Broken Window Effect.

I can’t think of a single case where imposing a high code coverage number on checkin,  up front, has resulted in the team writing better code and I can think of many cases where the reverse is true.

Now, the one case that I have seen work is where the team starts a mandatory code coverage based on where they are today and very gradually increases the mandatory amount over time to slowly improve. Although even that causes problems when new people are brought onto the team or new teams take over that code base.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.

On Dec 4, 2019, at 4:51 PM, John Maxwell <jmax@...> wrote:

On 12/04/2019 04:47:58 PM, Mike Bowler wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any
code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put
in place and the “quality” that results. I expect many of us here have
seen that disaster.

I haven't. What's the failure mechanism?

--
John Maxwell  KB3VLL  jmax@...

"Personally I'm fond of using Dedekind cuts for representing the Reals,
but it gets cumbersome to use when balancing one's checkbook."
       -Charles Haynes





Avi Kessner
 

Huh, this really got me thinking.
Here is what I would like to see if I had millions of dollars and lots of influence.

The Continuous Coding Foundation, which functions like an open source foundation for Continuous Coding practices. 
The foundation offers training and certification in graduated Continuous Coding practices.

Practices can belong to 1 of four levels. Abandoned, Sandbox, Incubation, and Graduated.

Examples of Abandoned practices, would be known antipatterns or projects which are found to have negative indicators when data is collected on them. For example, brittle tests.

An example of a sandbox practice would be Test && Commit || Revert. It's a well defined practice with a declared goal and has multiple articles on the topic. But lacks data on it's effectiveness, but could in theory have data collected and it's effectiveness proven.

An example of an Incubation practice would be Red Green Refactor. It's a common practice who's practitioners report gains when combined with other practices. But it lacks data on it's benefits when done in isolation , and there might be evidence that if done without full understanding, can cause harm.

Then an example of graduated would be practices which have been studied or reported on in academic /trade journals with clear data demonstrating that companies who adopt these practices deliver better software than those that don't.  For example, quick iterations between tests and production code.


On Thu, Dec 5, 2019, 00:34 Avi Kessner via Groups.Io <akessner=gmail.com@groups.io> wrote:
If I were to market XP today I would call it "Continuous Coding". So you do CC, then CI, then CD.  You could shorten this to C3, and bring XP back in a full circle.

On Wed, Dec 4, 2019, 23:22 Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin,

I think it’s a great idea to build a sellable brand for XP. How about 'Effective Programming', as in delivering results?

Slava

On Dec 4, 2019, at 10:42 AM, R Dymond <rdymond@...> wrote:

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
>
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
>
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
>
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R





Slava Imeshev <imeshev@...>
 

Yep. Something similar to Scrum / Agile Alliance would but for engineering practices would be great. Make it attractive to be certified as a software developer.

On Dec 4, 2019, at 3:14 PM, Avi Kessner <akessner@...> wrote:

Huh, this really got me thinking.
Here is what I would like to see if I had millions of dollars and lots of influence.

The Continuous Coding Foundation, which functions like an open source foundation for Continuous Coding practices. 
The foundation offers training and certification in graduated Continuous Coding practices.

Practices can belong to 1 of four levels. Abandoned, Sandbox, Incubation, and Graduated.

Examples of Abandoned practices, would be known antipatterns or projects which are found to have negative indicators when data is collected on them. For example, brittle tests.

An example of a sandbox practice would be Test && Commit || Revert. It's a well defined practice with a declared goal and has multiple articles on the topic. But lacks data on it's effectiveness, but could in theory have data collected and it's effectiveness proven.

An example of an Incubation practice would be Red Green Refactor. It's a common practice who's practitioners report gains when combined with other practices. But it lacks data on it's benefits when done in isolation , and there might be evidence that if done without full understanding, can cause harm.

Then an example of graduated would be practices which have been studied or reported on in academic /trade journals with clear data demonstrating that companies who adopt these practices deliver better software than those that don't.  For example, quick iterations between tests and production code.

On Thu, Dec 5, 2019, 00:34 Avi Kessner via Groups.Io <akessner=gmail.com@groups.io> wrote:
If I were to market XP today I would call it "Continuous Coding". So you do CC, then CI, then CD.  You could shorten this to C3, and bring XP back in a full circle.

On Wed, Dec 4, 2019, 23:22 Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin,

I think it’s a great idea to build a sellable brand for XP. How about 'Effective Programming', as in delivering results?

Slava

On Dec 4, 2019, at 10:42 AM, R Dymond <rdymond@...> wrote:

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
>
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
>
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
>
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R








James Holmes
 

I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."

I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.


thierry henrio
 

Hello Slava,

I'm with Mike an Jim.

Did you had a bug in production and go and see shows you covered code? What new test to write?
Did you had terrible performance? What new test to write?
To add some fuel, there are also undecidable problems, such as some parsing. Shall I write another test or ship?

Cheers,
Thierry

On Thu, Dec 5, 2019 at 12:06 AM Jim Shore <jshore@...> wrote:
My experience is the same as Mike’s.

_._,_._,_


Chet Hendrickson
 

On Dec 4, 2019, at 7:30 PM, thierry henrio <thierry.henrio@...> wrote:

Hello Slava,

I'm with Mike an Jim.

Did you had a bug in production and go and see shows you covered code? What new test to write?
Did you had terrible performance? What new test to write?
To add some fuel, there are also undecidable problems, such as some parsing. Shall I write another test or ship?

Cheers,
Thierry

On Thu, Dec 5, 2019 at 12:06 AM Jim Shore <jshore@...> wrote:
My experience is the same as Mike’s.



Slava Imeshev <imeshev@...>
 

Hi Thierry,

I don’t think it’s that black and white and we should be accounting for the context. Unit tests alone just prove that the tests work. And one can certainly write bad unit tests that don’t prove anything. So % of coverage alone is not enough. We need code reviews, integration testing, functional testing, performance testing, and stress testing to be fairly confident that the system is working. My own experience that once we have around 85-90% of coverage generated by the above practices we can start talking CD. We still need a measurable feedback on quality such as # of bugs escaping to production. 

With the said, one should start somewhere and to me personally knowing % of unit test coverage is a basic coding hygiene but this maybe different for someone else. 

As for the questions below, pls see inline.

Slava

On Dec 4, 2019, at 4:30 PM, thierry henrio <thierry.henrio@...> wrote:

Hello Slava,

I'm with Mike an Jim.

Did you had a bug in production and go and see shows you covered code? What new test to write?

This depends on the situation. Most of times bugs come from under-tested code. Sometimes from edge cases when requirements weren’t clearly understood. New tests must cover missed use cases. TDD works great here.

Did you had terrible performance? What new test to write?

This could be a long story. Sometimes micro-metrics work if it’s possible to measure ‘slow’ fast.

To add some fuel, there are also undecidable problems, such as some parsing. Shall I write another test or ship?

“We don’t test, but when we do we test in production” :-)


Cheers,
Thierry

On Thu, Dec 5, 2019 at 12:06 AM Jim Shore <jshore@...> wrote:
My experience is the same as Mike’s.



R Dymond
 

Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.

Regards 
Robin

On Wed, Dec 4, 2019, 5:44 PM <james.holmes@...> wrote:
I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."

I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.


Steve Gordon
 



On Wed, Dec 4, 2019 at 5:58 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Most of times bugs come from under-tested code. Sometimes from edge cases when requirements weren’t clearly understood. New tests must cover missed use cases. TDD works great here.


Slava,

How do you use TDD to write new tests for existing code?  How do you go from a discovered bug to knowing what unit tests to write for which objects?  How does TDD apply?
 


James Grenning
 

I warn people of the potential dysfunction of code coverage as a goal. Like Mike said: take out the checks and you still have 100%! For those tests you might as well buy a test generator; then you can get the 100% test coverage bonus for meeting your goals.

I suggest to people in code influenced by TDD and design skill, you get areas of 100% and 0%. Something that is a mix is probably a design problem.

This is what happens to my code. I have areas that are suitable for TDD and have 100% coverage (not because that is the goal, that is just what happens). Areas that are not suitable for TDD have 0% coverage and complexity of 1 or 2. They tend to be areas that do not change.

Cheers! James


James Grenning - Author of TDD for Embedded C - wingman-sw.com/tddec
wingman-sw.com
wingman-sw.com/blog
twitter.com/jwgrenning
facebook.com/wingman.sw
wingman software

On 4 Dec 2019, at 17:11, Slava Imeshev via Groups.Io wrote:

Of course we mean good tests. I’m doubtful that it’s possible to claim a good test without good coverage.

Slava

On Dec 4, 2019, at 2:05 PM, Mike Bowler <mbowler@...> wrote:

We rapidly get a collection of tests that increase code coverage without testing any actual behaviour. I’ve seen whole test setups with few or no assertions.  This is then worse than having low test coverage because we can’t trust any of it.

Then when the team is in the habit of writing garbage tests, that starts to leak into their production code and quality starts dropping there too. They care less about the quality. I expect this is some variant of Social Proof or the Broken Window Effect.

I can’t think of a single case where imposing a high code coverage number on checkin,  up front, has resulted in the team writing better code and I can think of many cases where the reverse is true.

Now, the one case that I have seen work is where the team starts a mandatory code coverage based on where they are today and very gradually increases the mandatory amount over time to slowly improve. Although even that causes problems when new people are brought onto the team or new teams take over that code base.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.

On Dec 4, 2019, at 4:51 PM, John Maxwell <jmax@...> wrote:

On 12/04/2019 04:47:58 PM, Mike Bowler wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any
code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put
in place and the “quality” that results. I expect many of us here have
seen that disaster.

I haven't. What's the failure mechanism?

--
John Maxwell  KB3VLL  jmax@...

"Personally I'm fond of using Dedekind cuts for representing the Reals,
but it gets cumbersome to use when balancing one's checkbook."
       -Charles Haynes





Slava Imeshev <imeshev@...>
 

1. Add a test that fails because the bug is there.
2. Make the test green by fixing the bug.
3. Check in.

On Dec 4, 2019, at 5:58 PM, Steve Gordon <sgordonphd@...> wrote:



On Wed, Dec 4, 2019 at 5:58 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Most of times bugs come from under-tested code. Sometimes from edge cases when requirements weren’t clearly understood. New tests must cover missed use cases. TDD works great here.


Slava,

How do you use TDD to write new tests for existing code?  How do you go from a discovered bug to knowing what unit tests to write for which objects?  How does TDD apply?
 


James Grenning
 

Hi Slava

I'd like to add a step.

James


On 4 Dec 2019, at 22:50, Slava Imeshev via Groups.Io wrote:

1. Add a test that fails because the bug is there.
1.5 Add some other tests to make sure you understand the code you want to change.
2. Make the test green by fixing the bug.
3. Check in.

On Dec 4, 2019, at 5:58 PM, Steve Gordon <sgordonphd@gmail.com> wrote:



On Wed, Dec 4, 2019 at 5:58 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
Most of times bugs come from under-tested code. Sometimes from edge cases when requirements weren’t clearly understood. New tests must cover missed use cases. TDD works great here.


Slava,

How do you use TDD to write new tests for existing code? How do you go from a discovered bug to knowing what unit tests to write for which objects? How does TDD apply?



Dave Nicolette
 

Just recently I worked with a team that achieved 100% line coverage with a single gigantic, meaningless test method. It was awesome!


On Wed, Dec 4, 2019, 22:48 Mike Bowler <mbowler@...> wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


James Grenning
 

Did they get their 100% test coverage bonus?


On 4 Dec 2019, at 23:30, Dave Nicolette wrote:

Just recently I worked with a team that achieved 100% line coverage with a single gigantic, meaningless test method. It was awesome!

On Wed, Dec 4, 2019, 22:48 Mike Bowler <mbowler@...> wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


James Grenning
 

Did the manager get their bonus?

On 4 Dec 2019, at 23:30, Dave Nicolette wrote:

Just recently I worked with a team that achieved 100% line coverage with a single gigantic, meaningless test method. It was awesome!

On Wed, Dec 4, 2019, 22:48 Mike Bowler <mbowler@...> wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


Slava Imeshev <imeshev@...>
 

Yes! In fact, that’s what I advise my team to do: do a method usage search and add tests that confirms that expectations for the method still work. It’s also good for understanding the codebase.

On Dec 4, 2019, at 8:23 PM, James Grenning <james@wingman-sw.com> wrote:

Hi Slava

I'd like to add a step.

James


On 4 Dec 2019, at 22:50, Slava Imeshev via Groups.Io wrote:

1. Add a test that fails because the bug is there.
1.5 Add some other tests to make sure you understand the code you want to change.
2. Make the test green by fixing the bug.
3. Check in.

On Dec 4, 2019, at 5:58 PM, Steve Gordon <sgordonphd@gmail.com> wrote:



On Wed, Dec 4, 2019 at 5:58 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
Most of times bugs come from under-tested code. Sometimes from edge cases when requirements weren’t clearly understood. New tests must cover missed use cases. TDD works great here.


Slava,

How do you use TDD to write new tests for existing code? How do you go from a discovered bug to knowing what unit tests to write for which objects? How does TDD apply?





James Grenning
 


I think XP is useful because it helps to solve real problems. I expect it to stay useful for people that use it to solve problems. 

On Dec 4, 2019 at 5:44 PM, james.holmes <james.holmes@...> wrote:

I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."

I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.


Dave Nicolette
 

Of course! Why else would they bother to write tests?

On 12/5/19, James Grenning <james@wingman-sw.com> wrote:
Did they get their 100% test coverage bonus?


On 4 Dec 2019, at 23:30, Dave Nicolette wrote:

Just recently I worked with a team that achieved 100% line coverage
with a
single gigantic, meaningless test method. It was awesome!

On Wed, Dec 4, 2019, 22:48 Mike Bowler <mbowler@gargoylesoftware.com>
wrote:

Yep. TDD is a holly grail. Just having a policy not to check in any
code
without 100% unit test coverage does wonders to quality.


I can’t tell if you meant that as sarcasm. I’ve seen that policy
put in
place and the “quality” that results. I expect many of us here
have seen
that disaster.

Mike Bowler
Agile & Technical, Coach and Trainer
Cell: 905 409-7052
www.GargoyleSoftware.com/mike_bowler
<http://www.gargoylesoftware.com/mike_bowler>
www.UnconsciousAgile.com <http://www.unconsciousagile.com/>

Ask about our Certified Scrum Developer (CSD) training classes
<http://www.gargoylesoftware.com/training/csd>. In-house and public
classes available.






Avi Kessner
 

Why would anyone get a bonus for doing what is required?
Requiring or expecting 100% code coverage is a very different practice from rewarding 100% code coverage. 
Don't confuse the two concepts.

On Thu, Dec 5, 2019, 06:34 James Grenning <james@...> wrote:

Did they get their 100% test coverage bonus?


On 4 Dec 2019, at 23:30, Dave Nicolette wrote:

Just recently I worked with a team that achieved 100% line coverage with a single gigantic, meaningless test method. It was awesome!

On Wed, Dec 4, 2019, 22:48 Mike Bowler <mbowler@...> wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


Dave Nicolette
 

Also don't confuse the concepts of humor and seriousness.


On Thu, Dec 5, 2019, 07:46 Avi Kessner <akessner@...> wrote:
Why would anyone get a bonus for doing what is required?
Requiring or expecting 100% code coverage is a very different practice from rewarding 100% code coverage. 
Don't confuse the two concepts.

On Thu, Dec 5, 2019, 06:34 James Grenning <james@...> wrote:

Did they get their 100% test coverage bonus?


On 4 Dec 2019, at 23:30, Dave Nicolette wrote:

Just recently I worked with a team that achieved 100% line coverage with a single gigantic, meaningless test method. It was awesome!

On Wed, Dec 4, 2019, 22:48 Mike Bowler <mbowler@...> wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


Ron Jeffries
 

Hello, James,

On Dec 4, 2019, at 6:44 PM, james.holmes@... wrote:

I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."

I pay a lot of attention to Scrum and its works and pomps, and I wouldn't characterize it that harshly. I'd like to have something that popular for development practices. Scrum is often executed very poorly, but it is well known. In the dev practices area, we have almost zero coverage compared to Scrum. 

As for certifications, I am opposed to them, unless they have actual meat. See the Agile Alliance policy statement on certifications. They do have one major advantage, however: they sell training. It's easy to be cynical about selling, but if we can't get people learning our ideas one way or another, we can't help them.

An issue with Scrum certifications is the apparent distance between "certified scrumMASTER" and mastery, which may or may not actually be confusing the market. I suspect it does not, because I don't believe any reasoning being thinks two days of training makes a master of anything. The real bug, I suspect, is that the CSM course went on for years and years without any real effort to make clear that it was the beginning, and without providing learning material for moving beyond the two days. Now, both Scrum Alliance and scrum.org have begun to push additional learning, which is a good thing. Possibly too little, too late.

I do believe, however, that the average Scrum "installation" is, if not Dark, at least Dimming, not delivering what it could for the organization, and quite often making the lives of the people at the code face worse. I also believe that the practices and understanding of what was called XP can help developers with that, if only we could reach them.

One would hope that whatever people do today would include some learning from the Scrum situation, to avoid as many of the problems as possible. That said, good ideas get watered down, often to the point of turning rotten. They always have, and, I fear, always will. I know of no way around that other than to keep trying.


I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered.

Honestly, I can't find much meat here. XP is valuable when people use its ideas properly and with skill. Scrum is exactly the same, valuable when done properly and with skill. 

XP is largely useless in the world, despite its value, because it has so little coverage. It's useful to the few who do it, and isn't helping the many more people who don't know it or don't use it.

Popularity isn't bad. Popularity is what makes a product successful. The trick is to have a good product, and, ideally when it's really just a collection of ideas, to have a collection that can't be misused or faked. Unfortunately, I don't know how to do that, and I suspect it's not possible.

I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.

This is an interesting viewpoint. I would say this: Scrum is simplified, and sold to look good. People, unfortunately, don't actually have to buy and install it in order to say they're doing Scrum. It's as if you could drive a junker and get the same nods and smiles as the guy with the expensive Porsche. Most bad Scrum is discernibly fake Scrum. I can find out how an organization is failing to do what Scrum says with a morning's work. Often it only takes two questions: tell me your worst problem, and then a question conditioned on that answer.

However, since the world is full of broken things, and since it takes good ideas to fix broken things, and since to fix lots of broken things, the good ideas have to sell well ... either we're simply screwed (which is possible), or we need to accept that selling well does not mean the product is bad.

I don't expect the above to change your view, but it should at least get you thinking about how to improve the world at large without a set of ideas that can catch on, which would be an interesting outcome if possible.

Otherwise, the problem comes down to selling -- showing, convincing, illuminating for people that these ideas, actually practiced, can help them have better results and a better life.

Ron Jeffries
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg


Ron Jeffries
 

Hmm ...

On Dec 4, 2019, at 8:03 PM, R Dymond <rdymond@...> wrote:

Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.

Hm. Heartfelt if not observably empathetic. :)

Regarding Scrum itself, I am coming to believe that its users (cf customers), by and large, probably do not agree that it is better, or, at best, might agree that it's better in some ways and [much] worse in others. I've pointed out to Howard that the Scrum Alliance doesn't know the answer to this question, and that they really should.

The issues with Scrum, from which we would need to learn, are probably more complex than I can write or even understand, but there are some components to consider:

  1. The initial dose needs to be followed by continuous learning, from the beginning.
  2. It would be desirable not to be able to just say "we're doing Scrum". Might be impossible.
  3. Certification without substance is very dangerous as well as powerful.
  4. Sale of developer-focused learning is quite difficult:
    1. Takes much more time;
    2. Costs more;
    3. Companies often spend less, not more, on dev training.

There are new things to learn as well, not least that we probably have to sell these ideas to developers, not so much to managers and executives. Managers and executives are important here, but we have to reach the developers. This will require a different kind of outreach than has worked for Scrum and many other management ideas. 

I don't think it'll be easy: in fact, presently I find the challenge very daunting, because the only approach I see requires vision, lots of community building, much energy, and money, a combination that is in short supply. 

My present concern is that the views expressed here by James Holmes, are pretty solidly entrenched in the developer community. I think those views are a bit mistaken, but they are consistent with the general developer outlook and approach to things. To the extent that James' thoughts here expressed a common strongly held view -- and I think they do -- it is quite possible that the Scrum Alliance, maybe even the Agile Alliance, cannot successfully "market" these ideas to developers.

That was the point of Chet's and my talk at, what, deliver:Agile a couple of years ago, "Abandon Agile", also described here. We may need to literally form a new "anti-Agile" community to support these ideas, abandoning the word "Agile" to the many ways it has been watered down and perverted.

Naturally, I'd prefer, and we should prefer, to build on what is already there, rather than create what would appear to be a counter-movement. I'm hoping, but less and less unless I can get some active assistance, to get the Scrum Alliance's help with this.

I want to underline a key point from above: it may be true that Scrum's customers like Scrum. I believe that by and large, Scrum's users quite often do not. This is a problem ... and an opportunity.

Ron Jeffries
Perfectionism is the voice of the oppressor -- Anne Lamott


Avi Kessner
 

My suggestion was based on the success of  CNCF, the existence of the CDF and the success of CI/CD and the annual report which gauges which companies are involved with CI/CD. As well as the confusion around the term DevOps.

Ofcourse, DevSecOps, ChatOps, AIOps, GitOps etc are watering that down a bit.  But CI/CD practices have their own set of successes without the XP label.  We need to get that same sort of benchmarks and stats for the coding process itself.

brought to you by the letters A, V, and I
and the number 47


On Thu, Dec 5, 2019 at 2:43 PM Ron Jeffries <ronjeffriesacm@...> wrote:
Hmm ...

On Dec 4, 2019, at 8:03 PM, R Dymond <rdymond@...> wrote:

Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.

Hm. Heartfelt if not observably empathetic. :)

Regarding Scrum itself, I am coming to believe that its users (cf customers), by and large, probably do not agree that it is better, or, at best, might agree that it's better in some ways and [much] worse in others. I've pointed out to Howard that the Scrum Alliance doesn't know the answer to this question, and that they really should.

The issues with Scrum, from which we would need to learn, are probably more complex than I can write or even understand, but there are some components to consider:

  1. The initial dose needs to be followed by continuous learning, from the beginning.
  2. It would be desirable not to be able to just say "we're doing Scrum". Might be impossible.
  3. Certification without substance is very dangerous as well as powerful.
  4. Sale of developer-focused learning is quite difficult:
    1. Takes much more time;
    2. Costs more;
    3. Companies often spend less, not more, on dev training.

There are new things to learn as well, not least that we probably have to sell these ideas to developers, not so much to managers and executives. Managers and executives are important here, but we have to reach the developers. This will require a different kind of outreach than has worked for Scrum and many other management ideas. 

I don't think it'll be easy: in fact, presently I find the challenge very daunting, because the only approach I see requires vision, lots of community building, much energy, and money, a combination that is in short supply. 

My present concern is that the views expressed here by James Holmes, are pretty solidly entrenched in the developer community. I think those views are a bit mistaken, but they are consistent with the general developer outlook and approach to things. To the extent that James' thoughts here expressed a common strongly held view -- and I think they do -- it is quite possible that the Scrum Alliance, maybe even the Agile Alliance, cannot successfully "market" these ideas to developers.

That was the point of Chet's and my talk at, what, deliver:Agile a couple of years ago, "Abandon Agile", also described here. We may need to literally form a new "anti-Agile" community to support these ideas, abandoning the word "Agile" to the many ways it has been watered down and perverted.

Naturally, I'd prefer, and we should prefer, to build on what is already there, rather than create what would appear to be a counter-movement. I'm hoping, but less and less unless I can get some active assistance, to get the Scrum Alliance's help with this.

I want to underline a key point from above: it may be true that Scrum's customers like Scrum. I believe that by and large, Scrum's users quite often do not. This is a problem ... and an opportunity.

Ron Jeffries
Perfectionism is the voice of the oppressor -- Anne Lamott


Phil Goodwin
 

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


On Wed, Dec 4, 2019, 10:50 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
1. Add a test that fails because the bug is there.
2. Make the test green by fixing the bug.
3. Check in.

On Dec 4, 2019, at 5:58 PM, Steve Gordon <sgordonphd@...> wrote:



On Wed, Dec 4, 2019 at 5:58 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Most of times bugs come from under-tested code. Sometimes from edge cases when requirements weren’t clearly understood. New tests must cover missed use cases. TDD works great here.


Slava,

How do you use TDD to write new tests for existing code?  How do you go from a discovered bug to knowing what unit tests to write for which objects?  How does TDD apply?
 


Ron Jeffries
 

FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@...> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti


Phil Goodwin
 

I'm just saying that you have to know what went wrong in order to write the test. I work in an area where there are a ton of integrations and environmental issues that can cause failures. Often the bugs we find have to do with accommodating external behaviors that we find surprising. TDD only helps you know that what you wrote matches you intentions. It takes another layer of (constant) work to align intentions with reality.


On Thu, Dec 5, 2019, 8:19 AM Ron Jeffries <ronjeffriesacm@...> wrote:
FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@...> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti


Steve Gordon
 

There are 3 distinct cases in my mind:

1. Trivial bug - it is obvious what we did wrong and we just correct it.  That case might involved fixing a few unit tests, but does not involve TDD.

2. What we did was wrong. - Rip out the wrong code and tests and start over with the right functional test.  This involves redoing the development using TDD, but TDD is no more or less useful that it is for normal development.

3. What we did was right, but we were missing a requirement - formulate a new user story and implement it.  This again involves TDD, but still in the ordinary way.

Saying "TDD works great here" implies a non-existent difference with how TDD works in normal development.
 


On Thu, Dec 5, 2019 at 6:19 AM Ron Jeffries <ronjeffriesacm@...> wrote:
FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@...> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti


Steve Gordon
 

On the other hand, I might be missing a magic trick here, so I was asking Slava if he has a way to apply TDD in the context of bug-fixing that I am unaware of.

On Thu, Dec 5, 2019 at 6:46 AM Steve Gordon via Groups.Io <sgordonphd=gmail.com@groups.io> wrote:

There are 3 distinct cases in my mind:

1. Trivial bug - it is obvious what we did wrong and we just correct it.  That case might involved fixing a few unit tests, but does not involve TDD.

2. What we did was wrong. - Rip out the wrong code and tests and start over with the right functional test.  This involves redoing the development using TDD, but TDD is no more or less useful that it is for normal development.

3. What we did was right, but we were missing a requirement - formulate a new user story and implement it.  This again involves TDD, but still in the ordinary way.

Saying "TDD works great here" implies a non-existent difference with how TDD works in normal development.
 


R Dymond
 

Interesting Avi!

Does anyone know if Kubernetes development was test driven?

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond


On Thu, Dec 5, 2019, 7:02 AM Avi Kessner <akessner@...> wrote:
My suggestion was based on the success of  CNCF, the existence of the CDF and the success of CI/CD and the annual report which gauges which companies are involved with CI/CD. As well as the confusion around the term DevOps.

Ofcourse, DevSecOps, ChatOps, AIOps, GitOps etc are watering that down a bit.  But CI/CD practices have their own set of successes without the XP label.  We need to get that same sort of benchmarks and stats for the coding process itself.

brought to you by the letters A, V, and I
and the number 47


On Thu, Dec 5, 2019 at 2:43 PM Ron Jeffries <ronjeffriesacm@...> wrote:
Hmm ...

On Dec 4, 2019, at 8:03 PM, R Dymond <rdymond@...> wrote:

Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.

Hm. Heartfelt if not observably empathetic. :)

Regarding Scrum itself, I am coming to believe that its users (cf customers), by and large, probably do not agree that it is better, or, at best, might agree that it's better in some ways and [much] worse in others. I've pointed out to Howard that the Scrum Alliance doesn't know the answer to this question, and that they really should.

The issues with Scrum, from which we would need to learn, are probably more complex than I can write or even understand, but there are some components to consider:

  1. The initial dose needs to be followed by continuous learning, from the beginning.
  2. It would be desirable not to be able to just say "we're doing Scrum". Might be impossible.
  3. Certification without substance is very dangerous as well as powerful.
  4. Sale of developer-focused learning is quite difficult:
    1. Takes much more time;
    2. Costs more;
    3. Companies often spend less, not more, on dev training.

There are new things to learn as well, not least that we probably have to sell these ideas to developers, not so much to managers and executives. Managers and executives are important here, but we have to reach the developers. This will require a different kind of outreach than has worked for Scrum and many other management ideas. 

I don't think it'll be easy: in fact, presently I find the challenge very daunting, because the only approach I see requires vision, lots of community building, much energy, and money, a combination that is in short supply. 

My present concern is that the views expressed here by James Holmes, are pretty solidly entrenched in the developer community. I think those views are a bit mistaken, but they are consistent with the general developer outlook and approach to things. To the extent that James' thoughts here expressed a common strongly held view -- and I think they do -- it is quite possible that the Scrum Alliance, maybe even the Agile Alliance, cannot successfully "market" these ideas to developers.

That was the point of Chet's and my talk at, what, deliver:Agile a couple of years ago, "Abandon Agile", also described here. We may need to literally form a new "anti-Agile" community to support these ideas, abandoning the word "Agile" to the many ways it has been watered down and perverted.

Naturally, I'd prefer, and we should prefer, to build on what is already there, rather than create what would appear to be a counter-movement. I'm hoping, but less and less unless I can get some active assistance, to get the Scrum Alliance's help with this.

I want to underline a key point from above: it may be true that Scrum's customers like Scrum. I believe that by and large, Scrum's users quite often do not. This is a problem ... and an opportunity.

Ron Jeffries
Perfectionism is the voice of the oppressor -- Anne Lamott


Avi Kessner
 

I don't know if it was test-driven or not but I do know they have a heavily automated process with an 800 core cluster running tests on every PR.
They have many bots for handling Github, and one of the early release team members actually automated his job away.

brought to you by the letters A, V, and I
and the number 47


On Thu, Dec 5, 2019 at 4:04 PM R Dymond <rdymond@...> wrote:
Interesting Avi!

Does anyone know if Kubernetes development was test driven?

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Thu, Dec 5, 2019, 7:02 AM Avi Kessner <akessner@...> wrote:
My suggestion was based on the success of  CNCF, the existence of the CDF and the success of CI/CD and the annual report which gauges which companies are involved with CI/CD. As well as the confusion around the term DevOps.

Ofcourse, DevSecOps, ChatOps, AIOps, GitOps etc are watering that down a bit.  But CI/CD practices have their own set of successes without the XP label.  We need to get that same sort of benchmarks and stats for the coding process itself.

brought to you by the letters A, V, and I
and the number 47


On Thu, Dec 5, 2019 at 2:43 PM Ron Jeffries <ronjeffriesacm@...> wrote:
Hmm ...

On Dec 4, 2019, at 8:03 PM, R Dymond <rdymond@...> wrote:

Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.

Hm. Heartfelt if not observably empathetic. :)

Regarding Scrum itself, I am coming to believe that its users (cf customers), by and large, probably do not agree that it is better, or, at best, might agree that it's better in some ways and [much] worse in others. I've pointed out to Howard that the Scrum Alliance doesn't know the answer to this question, and that they really should.

The issues with Scrum, from which we would need to learn, are probably more complex than I can write or even understand, but there are some components to consider:

  1. The initial dose needs to be followed by continuous learning, from the beginning.
  2. It would be desirable not to be able to just say "we're doing Scrum". Might be impossible.
  3. Certification without substance is very dangerous as well as powerful.
  4. Sale of developer-focused learning is quite difficult:
    1. Takes much more time;
    2. Costs more;
    3. Companies often spend less, not more, on dev training.

There are new things to learn as well, not least that we probably have to sell these ideas to developers, not so much to managers and executives. Managers and executives are important here, but we have to reach the developers. This will require a different kind of outreach than has worked for Scrum and many other management ideas. 

I don't think it'll be easy: in fact, presently I find the challenge very daunting, because the only approach I see requires vision, lots of community building, much energy, and money, a combination that is in short supply. 

My present concern is that the views expressed here by James Holmes, are pretty solidly entrenched in the developer community. I think those views are a bit mistaken, but they are consistent with the general developer outlook and approach to things. To the extent that James' thoughts here expressed a common strongly held view -- and I think they do -- it is quite possible that the Scrum Alliance, maybe even the Agile Alliance, cannot successfully "market" these ideas to developers.

That was the point of Chet's and my talk at, what, deliver:Agile a couple of years ago, "Abandon Agile", also described here. We may need to literally form a new "anti-Agile" community to support these ideas, abandoning the word "Agile" to the many ways it has been watered down and perverted.

Naturally, I'd prefer, and we should prefer, to build on what is already there, rather than create what would appear to be a counter-movement. I'm hoping, but less and less unless I can get some active assistance, to get the Scrum Alliance's help with this.

I want to underline a key point from above: it may be true that Scrum's customers like Scrum. I believe that by and large, Scrum's users quite often do not. This is a problem ... and an opportunity.

Ron Jeffries
Perfectionism is the voice of the oppressor -- Anne Lamott


James Grenning
 

Well Avi, it was a joke.

Though I have heard about test coverage incentives (hear say evidence). Personally, and likely for others that a have taken the time to learn TDD, having the tests are incentive enough.

Cheers, James


James Grenning - Author of TDD for Embedded C - wingman-sw.com/tddec
wingman-sw.com
wingman-sw.com/blog
twitter.com/jwgrenning
facebook.com/wingman.sw
wingman software

On 5 Dec 2019, at 1:46, Avi Kessner wrote:

Why would anyone get a bonus for doing what is required?
Requiring or expecting 100% code coverage is a very different practice from rewarding 100% code coverage. 
Don't confuse the two concepts.

On Thu, Dec 5, 2019, 06:34 James Grenning <james@...> wrote:

Did they get their 100% test coverage bonus?


On 4 Dec 2019, at 23:30, Dave Nicolette wrote:

Just recently I worked with a team that achieved 100% line coverage with a single gigantic, meaningless test method. It was awesome!

On Wed, Dec 4, 2019, 22:48 Mike Bowler <mbowler@...> wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


James Grenning
 

LOL!


On 5 Dec 2019, at 2:09, Dave Nicolette wrote:

Also don't confuse the concepts of humor and seriousness.

On Thu, Dec 5, 2019, 07:46 Avi Kessner <akessner@...> wrote:
Why would anyone get a bonus for doing what is required?
Requiring or expecting 100% code coverage is a very different practice from rewarding 100% code coverage. 
Don't confuse the two concepts.

On Thu, Dec 5, 2019, 06:34 James Grenning <james@...> wrote:

Did they get their 100% test coverage bonus?


On 4 Dec 2019, at 23:30, Dave Nicolette wrote:

Just recently I worked with a team that achieved 100% line coverage with a single gigantic, meaningless test method. It was awesome!

On Wed, Dec 4, 2019, 22:48 Mike Bowler <mbowler@...> wrote:
Yep. TDD is a holly grail. Just having a policy not to check in any code without 100% unit test coverage does wonders to quality.

I can’t tell if you meant that as sarcasm. I’ve seen that policy put in place and the “quality” that results. I expect many of us here have seen that disaster.

Mike Bowler
Agile & Technical, Coach and Trainerwww.GargoyleSoftware.com/mike_bowler
www.UnconsciousAgile.com

Ask about our Certified Scrum Developer (CSD) training classes. In-house and public classes available.


James Grenning
 

Likewise


On 5 Dec 2019, at 8:19, Ron Jeffries wrote:

FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@...> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti


James Grenning
 

This happens next to hardware:

1) test drive to the spec off the target hardware. (getting it almost right)
2) integrate with the hardware and find the places you got it wrong.
3) run the off-target tests to see in your tests what you got wrong
4) make the tests match the world


James Grenning - Author of TDD for Embedded C - wingman-sw.com/tddec
wingman-sw.com
wingman-sw.com/blog
twitter.com/jwgrenning
facebook.com/wingman.sw

On 5 Dec 2019, at 8:45, Steve Gordon wrote:

There are 3 distinct cases in my mind:

1. Trivial bug - it is obvious what we did wrong and we just correct it.  That case might involved fixing a few unit tests, but does not involve TDD.

2. What we did was wrong. - Rip out the wrong code and tests and start over with the right functional test.  This involves redoing the development using TDD, but TDD is no more or less useful that it is for normal development.

3. What we did was right, but we were missing a requirement - formulate a new user story and implement it.  This again involves TDD, but still in the ordinary way.

Saying "TDD works great here" implies a non-existent difference with how TDD works in normal development.
 

On Thu, Dec 5, 2019 at 6:19 AM Ron Jeffries <ronjeffriesacm@...> wrote:
FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@...> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti


Eb Alson
 

I believe XP (at the start) requires a level of discipline and rigor that many folks are not willing to commit to because they can create software without the discipline and rigor.

Something about human nature. :-)


On Wed, Dec 4, 2019 at 12:58 AM R Dymond <rdymond@...> wrote:
My first Agile project was in 2002, so not 20 years, however that first project we started with TDD, CC.net and monthly releases.

Since that time I have seen XP go from early adopter "awesome" to neglected stepchild of Scrum, to somewhat mysterious/intriguing ghost of development gurus past.

Reading Kent's posts from facebookland or some of the senior google alum I follow (ie Jeff Nelson chromebook inventor), it seems among these non XP practicing smart engineers Agile developer skills aren't considered necessary or required. That to me is sad though not unexpected. Developers have as much difficulty changing their habits as anyone else. Besides, we're too busy.

At a recent client that has success adopting Agile in their hardware manufacturing group, their software group remains a flailing mess, the current S/W project running millions over budget (waterfall) and the CTO recently fired for it. That CTO connected me with that S/W group before the sh*t show got rolling but they declined my services. 

That same fired CTO sponsored agile in 5 pilots, all hardware, and all delivering. In those pilots we emphasize less welding and more (overbuilt) interfaces (mostly ignored because if cost) more modularity, more standardization, and TDD thinking, which translates into hypothesis to test rig and interface, then design to pass. These are not quite unit tests, but somewhere between unit and functional tests. Selling these ideas in mechanical engineering teams today is like selling OO in the 90s. Some get it and love it, others don't care, and most are sorta neutral. 

By decoupling and enabling reuse we decrease the amount of engineering labour required to build new H/W systems. Many engineers do not think this is a good idea, since they're paid for every hour of engineering required ("and we're going to engineer the sh*t outa this thing"). Similarly, sales of standardized parts generate less profit then sales of specialized parts.  Case in point, try to mount wheels for a bmw on a similar sized sedan from another manufacturer. There are dozens bolt patterns to hold a wheel on a car, the reason for so many has to do with profit, not passing the test of holding a wheel on.

Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

To end on a more positive note, tool support has never been better!

Cheers Robin.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Tue, Dec 3, 2019, 12:42 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
George, thank you for raising the discussion to the top level.

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

7. Code reviews now must which is great.

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

Slava

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:


(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--




Steve Gordon
 

Sometimes the hardware is wrong.  Then the battle ensues whether or not the software should compensate for hardware errors.  For example, the 737MAX.


On Thu, Dec 5, 2019 at 7:24 AM James Grenning <james@...> wrote:

This happens next to hardware:

1) test drive to the spec off the target hardware. (getting it almost right)
2) integrate with the hardware and find the places you got it wrong.
3) run the off-target tests to see in your tests what you got wrong
4) make the tests match the world


James Grenning - Author of TDD for Embedded C - wingman-sw.com/tddec
wingman-sw.com
wingman-sw.com/blog
twitter.com/jwgrenning
facebook.com/wingman.sw

On 5 Dec 2019, at 8:45, Steve Gordon wrote:

There are 3 distinct cases in my mind:

1. Trivial bug - it is obvious what we did wrong and we just correct it.  That case might involved fixing a few unit tests, but does not involve TDD.

2. What we did was wrong. - Rip out the wrong code and tests and start over with the right functional test.  This involves redoing the development using TDD, but TDD is no more or less useful that it is for normal development.

3. What we did was right, but we were missing a requirement - formulate a new user story and implement it.  This again involves TDD, but still in the ordinary way.

Saying "TDD works great here" implies a non-existent difference with how TDD works in normal development.
 

On Thu, Dec 5, 2019 at 6:19 AM Ron Jeffries <ronjeffriesacm@...> wrote:
FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@...> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti


James Grenning
 


Sometimes the hardware spec is wrong and, as you mention,  sometimes the hardware is right sometimes and wrong other times.  I think there is a role for software in the latter. As we will see the MAX problem fixed in software. 

The opposite happens too.  Hardware is changed to address software problems. 

On Dec 5, 2019 at 10:04 AM, Steve Gordon <sgordonphd@...> wrote:

Sometimes the hardware is wrong.  Then the battle ensues whether or not the software should compensate for hardware errors.  For example, the 737MAX.

On Thu, Dec 5, 2019 at 7:24 AM James Grenning <james@...> wrote:

This happens next to hardware:

1) test drive to the spec off the target hardware. (getting it almost right)
2) integrate with the hardware and find the places you got it wrong.
3) run the off-target tests to see in your tests what you got wrong
4) make the tests match the world


James Grenning - Author of TDD for Embedded C - wingman-sw.com/tddec
wingman-sw.com
wingman-sw.com/blog
twitter.com/jwgrenning
facebook.com/wingman.sw

On 5 Dec 2019, at 8:45, Steve Gordon wrote:

There are 3 distinct cases in my mind:

1. Trivial bug - it is obvious what we did wrong and we just correct it.  That case might involved fixing a few unit tests, but does not involve TDD.

2. What we did was wrong. - Rip out the wrong code and tests and start over with the right functional test.  This involves redoing the development using TDD, but TDD is no more or less useful that it is for normal development.

3. What we did was right, but we were missing a requirement - formulate a new user story and implement it.  This again involves TDD, but still in the ordinary way.

Saying "TDD works great here" implies a non-existent difference with how TDD works in normal development.
 

On Thu, Dec 5, 2019 at 6:19 AM Ron Jeffries <ronjeffriesacm@...> wrote:
FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@...> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti



Steve Gordon
 

It is debatable whether the software actually fixed the MAX problem.


On Thu, Dec 5, 2019 at 9:28 AM James Grenning <james@...> wrote:

Sometimes the hardware spec is wrong and, as you mention,  sometimes the hardware is right sometimes and wrong other times.  I think there is a role for software in the latter. As we will see the MAX problem fixed in software. 

The opposite happens too.  Hardware is changed to address software problems. 

On Dec 5, 2019 at 10:04 AM, Steve Gordon <sgordonphd@...> wrote:

Sometimes the hardware is wrong.  Then the battle ensues whether or not the software should compensate for hardware errors.  For example, the 737MAX.

On Thu, Dec 5, 2019 at 7:24 AM James Grenning <james@...> wrote:

This happens next to hardware:

1) test drive to the spec off the target hardware. (getting it almost right)
2) integrate with the hardware and find the places you got it wrong.
3) run the off-target tests to see in your tests what you got wrong
4) make the tests match the world


James Grenning - Author of TDD for Embedded C - wingman-sw.com/tddec
wingman-sw.com
wingman-sw.com/blog
twitter.com/jwgrenning
facebook.com/wingman.sw

On 5 Dec 2019, at 8:45, Steve Gordon wrote:

There are 3 distinct cases in my mind:

1. Trivial bug - it is obvious what we did wrong and we just correct it.  That case might involved fixing a few unit tests, but does not involve TDD.

2. What we did was wrong. - Rip out the wrong code and tests and start over with the right functional test.  This involves redoing the development using TDD, but TDD is no more or less useful that it is for normal development.

3. What we did was right, but we were missing a requirement - formulate a new user story and implement it.  This again involves TDD, but still in the ordinary way.

Saying "TDD works great here" implies a non-existent difference with how TDD works in normal development.
 

On Thu, Dec 5, 2019 at 6:19 AM Ron Jeffries <ronjeffriesacm@...> wrote:
FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@...> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.


Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti



Phil Goodwin
 

Right. I work at Pivotal where we have a consulting arm that teaches XP and an R&D organization that employs it. What I've seen is that there are good reasons to step away from the disciplines -- pairing isn't great for learning a new technology from scratch or doing certain tedious tasks (though it's good for those that are so tedious that attention might stray); TDD doesn't work well for some kinds of integration work that requires a lot of exploration; continuous integration is impractical when test suites take a long time to run -- and that organizations and the individuals that comprise them want to step away from those disciplines for the wrong reasons, mostly having to do with ego, easy gratification, and fear. Disciplines always don't work without character to run them, and that's something that has to be remade over and over again.

On Thu, Dec 5, 2019 at 6:53 AM Eb Alson <amaeze@...> wrote:
I believe XP (at the start) requires a level of discipline and rigor that many folks are not willing to commit to because they can create software without the discipline and rigor.

Something about human nature. :-)

On Wed, Dec 4, 2019 at 12:58 AM R Dymond <rdymond@...> wrote:
My first Agile project was in 2002, so not 20 years, however that first project we started with TDD, CC.net and monthly releases.

Since that time I have seen XP go from early adopter "awesome" to neglected stepchild of Scrum, to somewhat mysterious/intriguing ghost of development gurus past.

Reading Kent's posts from facebookland or some of the senior google alum I follow (ie Jeff Nelson chromebook inventor), it seems among these non XP practicing smart engineers Agile developer skills aren't considered necessary or required. That to me is sad though not unexpected. Developers have as much difficulty changing their habits as anyone else. Besides, we're too busy.

At a recent client that has success adopting Agile in their hardware manufacturing group, their software group remains a flailing mess, the current S/W project running millions over budget (waterfall) and the CTO recently fired for it. That CTO connected me with that S/W group before the sh*t show got rolling but they declined my services. 

That same fired CTO sponsored agile in 5 pilots, all hardware, and all delivering. In those pilots we emphasize less welding and more (overbuilt) interfaces (mostly ignored because if cost) more modularity, more standardization, and TDD thinking, which translates into hypothesis to test rig and interface, then design to pass. These are not quite unit tests, but somewhere between unit and functional tests. Selling these ideas in mechanical engineering teams today is like selling OO in the 90s. Some get it and love it, others don't care, and most are sorta neutral. 

By decoupling and enabling reuse we decrease the amount of engineering labour required to build new H/W systems. Many engineers do not think this is a good idea, since they're paid for every hour of engineering required ("and we're going to engineer the sh*t outa this thing"). Similarly, sales of standardized parts generate less profit then sales of specialized parts.  Case in point, try to mount wheels for a bmw on a similar sized sedan from another manufacturer. There are dozens bolt patterns to hold a wheel on a car, the reason for so many has to do with profit, not passing the test of holding a wheel on.

Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.

So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

To end on a more positive note, tool support has never been better!

Cheers Robin.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Tue, Dec 3, 2019, 12:42 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
George, thank you for raising the discussion to the top level.

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

7. Code reviews now must which is great.

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

Slava

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:


(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?
Date: Tue, 29 Oct 2019 08:39:12 -0700
From: Jay Bazuzi <jay@...>
Reply-To: extremeprogramming@groups.io
To: extremeprogramming@groups.io


From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

That seems to match your experience, JB.

-J

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:
On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:
Thanks, JB,

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.
--



--


Slava Imeshev <imeshev@...>
 

Definitely. That wasn't a attempt to dig into the complete lifecycle of a bug.

On Thursday, December 5, 2019, 5:12:18 AM PST, Phil Goodwin <phil.goodwin@...> wrote:


Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.

On Wed, Dec 4, 2019, 10:50 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
1. Add a test that fails because the bug is there.
2. Make the test green by fixing the bug.
3. Check in.

On Dec 4, 2019, at 5:58 PM, Steve Gordon <sgordonphd@...> wrote:



On Wed, Dec 4, 2019 at 5:58 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Most of times bugs come from under-tested code. Sometimes from edge cases when requirements weren’t clearly understood. New tests must cover missed use cases. TDD works great here.


Slava,

How do you use TDD to write new tests for existing code?  How do you go from a discovered bug to knowing what unit tests to write for which objects?  How does TDD apply?
 


Slava Imeshev <imeshev@...>
 

I was just trying to reinforce the value of TDD in this particular context. This may not be a worthy exercise in this group because everyone is already sold on it. Still, in my practice, I find it effective to couch developers on the test->fix->test loop.

Same time, I don't think we should treat XP practices as a religion. In case of TDD, if someone gets in the flow and cranks out 500 lines of great code in a day and then spends the next day writing tests, that's fine with me because flow is more important than following a particular practices to the letter.

Slava

On Thursday, December 5, 2019, 5:50:18 AM PST, Steve Gordon <sgordonphd@...> wrote:


On the other hand, I might be missing a magic trick here, so I was asking Slava if he has a way to apply TDD in the context of bug-fixing that I am unaware of.

On Thu, Dec 5, 2019 at 6:46 AM Steve Gordon via Groups.Io <sgordonphd=gmail.com@groups.io> wrote:
There are 3 distinct cases in my mind:

1. Trivial bug - it is obvious what we did wrong and we just correct it.  That case might involved fixing a few unit tests, but does not involve TDD.

2. What we did was wrong. - Rip out the wrong code and tests and start over with the right functional test.  This involves redoing the development using TDD, but TDD is no more or less useful that it is for normal development.

3. What we did was right, but we were missing a requirement - formulate a new user story and implement it.  This again involves TDD, but still in the ordinary way.

Saying "TDD works great here" implies a non-existent difference with how TDD works in normal development.
 


George Paci
 

I am definitely stealing this term and spreading it.

"If you want to do Continuous Delivery, you need to do Continuous Integration. And if you want to do Continuous Integration, you need to do Continuous Coding."

Memorable.  Also true.

—George

  Laziness is nothing more than the habit of resting before you get tired.
      - Jules Renard

On 12/4/19 5:33 PM, Avi Kessner wrote:
If I were to market XP today I would call it "Continuous Coding". So you do CC, then CI, then CD.  You could shorten this to C3, and bring XP back in a full circle.

On Wed, Dec 4, 2019, 23:22 Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin,

I think it’s a great idea to build a sellable brand for XP. How about 'Effective Programming', as in delivering results?

Slava

On Dec 4, 2019, at 10:42 AM, R Dymond <rdymond@...> wrote:

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
>
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
>
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
>
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R





George Paci
 


On 12/5/19 7:43 AM, Ron Jeffries wrote:
[snip]
Sale of developer-focused learning is quite difficult:
    1. Takes much more time;
    2. Costs more;
    3. Companies often spend less, not more, on dev training.

... we have to reach the developers. This will require a different kind of outreach than has worked for Scrum and many other management ideas. 

+1e6



Steve Berczuk
 

It's good to hear Ron say this. When I first dove deep into Testing
more (not always TDD, but certainly testing a lot more, and writing
the tests before I committed any code), I ended up debugging less, and
started getting Judgmental (or at least curious) looks from some
colleagues when they realized that I didn't have all the keyboard
shortcuts for the debugger memorized.

(on the other hand, the more tools and languages one knows, it's not
reasonable to know all of the deep secrets of each tool)

Steve

On Thu, Dec 5, 2019 at 8:19 AM Ron Jeffries <ronjeffriesacm@gmail.com> wrote:

FWIW I [almost] never debug. In most languages I don't even know how to run the debugger. Once in a while, rarely, I'll stuff in a print. Generally, I just write a test that fails.

On Dec 5, 2019, at 8:11 AM, Phil Goodwin <phil.goodwin@gmail.com> wrote:

Right. There's a step zero involving good old fashioned debugging to find the root cause, but then it makes sense to test drive the solution for all the trains it makes sense to TDD in the first place.



Ron Jeffries
ronjeffries.com
Whenever I feel discouraged, I remember the words of my then-3 yr old after she puked carrots on the floor: “I’m gonna need more carrots.”
— @JessicaValenti

--
Steve Berczuk | steve.berczuk@gmail.com | http://www.berczuk.com | @sberczuk
SaneBox keeps my inbox clean, try it here: http://sanebox.com/t/87l4z


Slava Imeshev <imeshev@...>
 

There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:

1. Textbooks combined with guided self-study.
2. Udemy/Cousera/Youtube video courses.
3. Reference cards to be given to new hires ("This is how we do it here").
4. Continuous stream of talks at conferences and meetups.
5. Magazine articles.
6. Study groups.
5. A mobile app with references.

What else?

Slava

On Thursday, December 5, 2019, 11:42:33 AM PST, George Paci <gpaci@...> wrote:



On 12/5/19 7:43 AM, Ron Jeffries wrote:
[snip]
Sale of developer-focused learning is quite difficult:
    1. Takes much more time;
    2. Costs more;
    3. Companies often spend less, not more, on dev training.

... we have to reach the developers. This will require a different kind of outreach than has worked for Scrum and many other management ideas. 

+1e6



Avi Kessner
 

What a great way to phrase it!


On Thu, Dec 5, 2019, 21:36 George Paci <gpaci@...> wrote:

I am definitely stealing this term and spreading it.

"If you want to do Continuous Delivery, you need to do Continuous Integration. And if you want to do Continuous Integration, you need to do Continuous Coding."

Memorable.  Also true.

—George

  Laziness is nothing more than the habit of resting before you get tired.
      - Jules Renard

On 12/4/19 5:33 PM, Avi Kessner wrote:
If I were to market XP today I would call it "Continuous Coding". So you do CC, then CI, then CD.  You could shorten this to C3, and bring XP back in a full circle.

On Wed, Dec 4, 2019, 23:22 Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin,

I think it’s a great idea to build a sellable brand for XP. How about 'Effective Programming', as in delivering results?

Slava

On Dec 4, 2019, at 10:42 AM, R Dymond <rdymond@...> wrote:

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
>
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
>
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
>
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R





Avi Kessner
 

George, thanks for the inspiration.
I've created a small placeholder site and registered a domain.  Accepting all Pull requests.
https://github.com/Daganev/continuouscoding.org  
brought to you by the letters A, V, and I
and the number 47


On Thu, Dec 5, 2019 at 9:36 PM George Paci <gpaci@...> wrote:

I am definitely stealing this term and spreading it.

"If you want to do Continuous Delivery, you need to do Continuous Integration. And if you want to do Continuous Integration, you need to do Continuous Coding."

Memorable.  Also true.

—George

  Laziness is nothing more than the habit of resting before you get tired.
      - Jules Renard

On 12/4/19 5:33 PM, Avi Kessner wrote:
If I were to market XP today I would call it "Continuous Coding". So you do CC, then CI, then CD.  You could shorten this to C3, and bring XP back in a full circle.

On Wed, Dec 4, 2019, 23:22 Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Robin,

I think it’s a great idea to build a sellable brand for XP. How about 'Effective Programming', as in delivering results?

Slava

On Dec 4, 2019, at 10:42 AM, R Dymond <rdymond@...> wrote:

Hey Ron!

Yes I believe Howard could invest *a lot* if he saw a route to growing these practices.

A couple ideas:
Agree that this needs a major rebranding. "Safe" sells, "extreme" is a terrible brand for an industry practice. James Gosling, working at Sun got marketing and branding involved and thats why we got the great branding for Java.

How do we make these ideas cool? Can we get the top tech celebrities advocating and pitching for these ideas? By celebs I mean mainstream tech celebs like Linus Torvalds, some of these guys https://www.quora.com/Who-are-the-best-engineers-at-Google-Why
And also tech business leaders who can influence the CXO crowd.


Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Wed, Dec 4, 2019, 9:17 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Robin,

Nice to see you here!

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 4, 2019, at 12:58 AM, R Dymond <rdymond@...> wrote:
>
> Being in the Scrum camp more than XP, in every CSM I overview in detail TDD, CI, Pairing, Mobbing and Swarming. Also explain that you have to look at XP,  not Scrum for great ideas on how to make great quality software.

I wish we knew how many CSTs do that. I think what we do know is that even that apparently doesn't work, as your own story below tells.
>
> I am at a loss on how to sell these ideas though. At a client who I started working with Scrum in 2010 I have trained most the staff on Scrum. They have over 1000 developers. We sold a total of 2 XP/TDD immersion courses with a well known XP Coach after strenuous internal marketing from HR and finally a Dev Sr Mgr assigning people to the classes. This same company spends millions per year on dev training and regularly sell out courses on Swift, C++, python, r, react, vmware, AWS, Azure, tensorflow etc. etc. Budget isn't the issue, demand for XP practices training is the struggle.
>
> So in 20 years we still do not have the business case we need to convince developers to widely adopt and spread these ideas.

It's a puzzlement. I've been talking with Howard Sublett (Scrum Alliance Chief Product Owner, for those who don't know) about the developer problem. He's interested, and I think he'd put some money behind it, but I'm at a loss as to how to effectively help. It's not clear what to do.

Ah well,

R





Ron Jeffries
 

Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@acm.org is a better address for me, maybe.

On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:

There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:

1. Textbooks combined with guided self-study.
2. Udemy/Cousera/Youtube video courses.
3. Reference cards to be given to new hires ("This is how we do it here").
4. Continuous stream of talks at conferences and meetups.
5. Magazine articles.
6. Study groups.
5. A mobile app with references.

What else?
Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R


Steve Gordon
 

These kind of resources have been around for decades in various forms.  They do help the 30% of developers who both care and have the ability to learn well passively.  There are lots of unmotivated developers just doing their job,  And there are lots of developers who can only learn effectively by working with others who already get it.

This is the main reason I like Scrum despite all the shortcomings.  It puts developers into a position where they are responsible for the results of their work, not just for doing what a manager tells them to do.  It includes explicit retrospection to reinforce the responsibility to improve.  It creates a social structure where team members can learn from working with each other.  It has more opportunity for effective coaching than ad hoc or waterfall development.


On Thu, Dec 5, 2019 at 2:36 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:

1. Textbooks combined with guided self-study.
2. Udemy/Cousera/Youtube video courses.
3. Reference cards to be given to new hires ("This is how we do it here").
4. Continuous stream of talks at conferences and meetups.
5. Magazine articles.
6. Study groups.
5. A mobile app with references.

What else?

Slava

On Thursday, December 5, 2019, 11:42:33 AM PST, George Paci <gpaci@...> wrote:



On 12/5/19 7:43 AM, Ron Jeffries wrote:
[snip]
Sale of developer-focused learning is quite difficult:
    1. Takes much more time;
    2. Costs more;
    3. Companies often spend less, not more, on dev training.

... we have to reach the developers. This will require a different kind of outreach than has worked for Scrum and many other management ideas. 

+1e6



R Dymond
 

CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond


On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R




Eb Alson
 

Under what circumstances should a leader impose any of these practices?

On Fri, Dec 6, 2019 at 9:58 AM R Dymond <rdymond@...> wrote:
CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R




R Dymond
 



On Fri, Dec 6, 2019, 8:01 AM Eb Alson <amaeze@...> wrote:
Under what circumstances should a leader impose any of these practices?

I think that was his question as well.


On Fri, Dec 6, 2019 at 9:58 AM R Dymond <rdymond@...> wrote:
CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R



--


Ron Jeffries
 

Here's how I'd impose Agile:


R

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

On Dec 6, 2019, at 10:01 AM, Eb Alson <amaeze@...> wrote:

Under what circumstances should a leader impose any of these practices?


Steve Gordon
 

Right.  Impose standards and goals, not how to achieve them.  And then offer support, including helping teams learn how to achieve those standards and goals.


On Fri, Dec 6, 2019 at 8:40 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Here's how I'd impose Agile:


R

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

On Dec 6, 2019, at 10:01 AM, Eb Alson <amaeze@...> wrote:

Under what circumstances should a leader impose any of these practices?


Eb Alson
 

Imposing at the right altitude is critical then because “Using XP or doing TDD“ can also be the goal/standard  that a CTO sets.

On Fri, Dec 6, 2019 at 11:18 AM Steve Gordon <sgordonphd@...> wrote:
Right.  Impose standards and goals, not how to achieve them.  And then offer support, including helping teams learn how to achieve those standards and goals.



Your Subscription | Contact Group Owner


Steve Gordon
 

By standards, I mean things like quality, bug rates, customer satisfaction.  I DO NOT mean how the work is done.  

It is best that the teams learn for themselves (with help, perhaps) what engineering practices they need to do in their context to achieve those standards, because then they are responsible for quality, not just blindly doing things the way they are told.  When problems, come up, they can see that slacking on what they themselves decided they should do was responsible.  If they are just doing what they are told, then whoever is telling them what to do is ultimately responsible, so learning and improvement peters out really quickly.

On Fri, Dec 6, 2019 at 10:04 AM Eb Alson <amaeze@...> wrote:
Imposing at the right altitude is critical then because “Using XP or doing TDD“ can also be the goal/standard  that a CTO sets.

On Fri, Dec 6, 2019 at 11:18 AM Steve Gordon <sgordonphd@...> wrote:
Right.  Impose standards and goals, not how to achieve them.  And then offer support, including helping teams learn how to achieve those standards and goals.



Your Subscription | Contact Group Owner

--


JeffGrigg
 

Something I've seen that was quite successful ...
1. During the hiring process, the company made it quite clear that Extreme Programming, including Pair Programming and the other practices was mandatory.
2. In the team's room, there are half as many machines as developers. "You work it out." says the boss.  (And you're kind of strongly expected to do "pair programming" of some kind. And if people quit, an appropriate number of machines will be removed.)

Actually...  It worked quite well.

The teams were enabled and empowered to change the process as they saw fit.  ... within "reasonable" bounds.

Some did kanban boards.  Some did big visible charts.  Some had timers to signal pair switching.

People knew before being hired what they were signing up for.  And then we did it.


James Grenning
 

Mandating TDD would be like mandating that all shots in pool be bank shots.  Unless someone had the skill in bank shots,  not many balks will be pocketed. 

TDD and bank shots require skill to execute.  Skills take time to learn. 

Mandating test automation is a business decision, as the cost of manual retest is so high. There are skills to learn here too, though maybe less difficult to get started. 

James

On Dec 6, 2019 at 9:37 AM, R Dymond <rdymond@...> wrote:



On Fri, Dec 6, 2019, 8:01 AM Eb Alson <amaeze@...> wrote:
Under what circumstances should a leader impose any of these practices?

I think that was his question as well.


On Fri, Dec 6, 2019 at 9:58 AM R Dymond <rdymond@...> wrote:
CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R



--



Slava Imeshev <imeshev@...>
 

I’m not sure if mandating alone would help. Continuous education and encouragement is needed to give and maintain the skills until they become a habit.

Slava

On Dec 6, 2019, at 11:11 AM, James Grenning <james@...> wrote:

Mandating TDD would be like mandating that all shots in pool be bank shots.  Unless someone had the skill in bank shots,  not many balks will be pocketed. 

TDD and bank shots require skill to execute.  Skills take time to learn. 

Mandating test automation is a business decision, as the cost of manual retest is so high. There are skills to learn here too, though maybe less difficult to get started. 

James

On Dec 6, 2019 at 9:37 AM, R Dymond <rdymond@...> wrote:



On Fri, Dec 6, 2019, 8:01 AM Eb Alson <amaeze@...> wrote:
Under what circumstances should a leader impose any of these practices?

I think that was his question as well.


On Fri, Dec 6, 2019 at 9:58 AM R Dymond <rdymond@...> wrote:
CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R





--





Slava Imeshev <imeshev@...>
 


On Dec 6, 2019, at 7:01 AM, Eb Alson <amaeze@...> wrote:

Under what circumstances should a leader impose any of these practices?

How about needing to have things done?

Slava


On Fri, Dec 6, 2019 at 9:58 AM R Dymond <rdymond@...> wrote:
CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R





--


Eb Alson
 

I think when hiring this might be ok. Maybe. It’s setting up the constraints as people come in especially with a brand new team. It’s different when people were hired under different circumstances and now you’re introducing these practices.

On Fri, Dec 6, 2019 at 12:22 PM JeffGrigg <jeffreytoddgrigg@...> wrote:
Something I've seen that was quite successful ...
1. During the hiring process, the company made it quite clear that Extreme Programming, including Pair Programming and the other practices was mandatory.
2. In the team's room, there are half as many machines as developers. "You work it out." says the boss.  (And you're kind of strongly expected to do "pair programming" of some kind. And if people quit, an appropriate number of machines will be removed.)

Actually...  It worked quite well.

The teams were enabled and empowered to change the process as they saw fit.  ... within "reasonable" bounds.

Some did kanban boards.  Some did big visible charts.  Some had timers to signal pair switching.

People knew before being hired what they were signing up for.  And then we did it.


Eb Alson
 

Sorry don’t understand.

On Fri, Dec 6, 2019 at 2:19 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:

On Dec 6, 2019, at 7:01 AM, Eb Alson <amaeze@...> wrote:

Under what circumstances should a leader impose any of these practices?

How about needing to have things done?

Slava


On Fri, Dec 6, 2019 at 9:58 AM R Dymond <rdymond@...> wrote:
CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R






Ron Jeffries
 

In my view this should never, ever, be done:

On Dec 6, 2019, at 12:03 PM, Eb Alson <amaeze@...> wrote:

Imposing at the right altitude is critical then because “Using XP or doing TDD“ can also be the goal/standard  that a CTO sets.


Ron Jeffries
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg


R Dymond
 

Agreed James. I would be much more comfortable mandating test automation, otherwise as you said a lot of cost for manual work is incurred... and isnt the business reason for software development often about eliminating manual tedious work with automation?

Also comfortable mandating Agile since it lowers the risk of loss in product development.

I would rather have people build their skills in a way that mixes curiosity and mentorship. Having a culture of encouragement and leadership that values these ideas seems a better way to engage the interested. This is where celebrity devs could increase broad interest.



On Fri, Dec 6, 2019, 12:11 PM James Grenning <james@...> wrote:
Mandating TDD would be like mandating that all shots in pool be bank shots.  Unless someone had the skill in bank shots,  not many balks will be pocketed. 

TDD and bank shots require skill to execute.  Skills take time to learn. 

Mandating test automation is a business decision, as the cost of manual retest is so high. There are skills to learn here too, though maybe less difficult to get started. 

James

On Dec 6, 2019 at 9:37 AM, R Dymond <rdymond@...> wrote:



On Fri, Dec 6, 2019, 8:01 AM Eb Alson <amaeze@...> wrote:
Under what circumstances should a leader impose any of these practices?

I think that was his question as well.


On Fri, Dec 6, 2019 at 9:58 AM R Dymond <rdymond@...> wrote:
CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R



--



Slava Imeshev <imeshev@...>
 

Imposing best practices may be needed to get things done. For example:

- The quality may not be where it should be. Add unit testing and TDD.
- The team is overworked. Add planning game.
- Projects are late. Add CI.

Etc...

I stopped believing in team's self-organization long ago. There are luminaries like XP founders. There are amazing individuals who can do it and and I worked with them.  Those usually make up 5-10% of them team. The rest requires couching, education, encouragement, pushing forward and yes, imposing and enforcing best practices because were are paid for getting stuff done in time and with quality. Without imposing, as harsh as this word can be, teams descent to run-as-they can 80 hour weeks... 

Slava

On Dec 6, 2019, at 11:31 AM, Eb Alson <amaeze@...> wrote:

Sorry don’t understand.

On Fri, Dec 6, 2019 at 2:19 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:

On Dec 6, 2019, at 7:01 AM, Eb Alson <amaeze@...> wrote:

Under what circumstances should a leader impose any of these practices?

How about needing to have things done?

Slava


On Fri, Dec 6, 2019 at 9:58 AM R Dymond <rdymond@...> wrote:
CNCF is really impressive. That growth! It is underwritten by linux foundation and google.

I was discussing TDD with a leader in a software company that just closed a $40M round and expects to grow from 19 to 40 teams. He said they have some teams who do TDD and pairing all the time, some who do it only on harder stuff and some who do not. They have some former thoughtworks alumni and many junior staff, and given the difficulty of recruiting senior staff in their location they expect many of their new hires to be 0 to 3 years of experience.

He has had the experience of being in company where they mandated TDD and pairing, then had some people leave and other people who wanted to work that way join.

So it is a puzzle to him as well. He doesn't feel he can mandate it at this point, and also he would prefer pull to push.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 7:13 AM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi ...

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

> On Dec 5, 2019, at 4:36 PM, Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
>
> There may be many more ways to accomplish this without doing it Scrum way. Just a few initial ideas:
>
> 1. Textbooks combined with guided self-study.
> 2. Udemy/Cousera/Youtube video courses.
> 3. Reference cards to be given to new hires ("This is how we do it here").
> 4. Continuous stream of talks at conferences and meetups.
> 5. Magazine articles.
> 6. Study groups.
> 5. A mobile app with references.
>
> What else?

Yes I think there are ways like that, and they are needed. I believe that the price has to be low enough that developers themselves will pay it if need be. This makes me think that, in early days at least, until volumes come up -- if they do -- the creation of these things needs to be underweritten.

R







--


R Dymond
 

Been there, done that (sorta).

 In a startup with a junior crew, had every dev pair with a TW consultant to learn TDD and CI. It was 2002 and we were the first outside thoughtworks to use CC.net. we ran with cc.net and some devs doing tdd some not. Ran that way for a year.

Then they lost their investor and downsized, I left. After I left the remaining team abandoned tdd (except one infected dev), and soon after turned off cc.net. Eventually, they did choose to revive cc.net, 3 years later.

I was shocked when I heard the devs chose to abandon disciplines that had helped to save the business. It took them 3 years to mature to a point where they recognized the value of CI. I doubt they do tdd. Since that time I have been involved with many Agile transitions and seen the same patterns in adopting Scrum and Agile.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 12:43 PM Ron Jeffries <ronjeffriesacm@...> wrote:
In my view this should never, ever, be done:

On Dec 6, 2019, at 12:03 PM, Eb Alson <amaeze@...> wrote:

Imposing at the right altitude is critical then because “Using XP or doing TDD“ can also be the goal/standard  that a CTO sets.


Ron Jeffries
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg


Ron Jeffries
 

It is my view that mandating any practice is directly counter both to the Scrum Guide and to the Manifesto.

Scrum Guide says that the team decides how to do the work. Manifesto says self-organization about 93 times.

Mandate results, not method.

On Dec 6, 2019, at 2:43 PM, R Dymond <rdymond@...> wrote:

Agreed James. I would be much more comfortable mandating test automation, otherwise as you said a lot of cost for manual work is incurred... and isnt the business reason for software development often about eliminating manual tedious work with automation?

Also comfortable mandating Agile since it lowers the risk of loss in product development.

I would rather have people build their skills in a way that mixes curiosity and mentorship. Having a culture of encouragement and leadership that values these ideas seems a better way to engage the interested. This is where celebrity devs could increase broad interest.


Ron Jeffries
It was important to me that we accumulate the learnings about the application over time by modifying the program to look as if we had known what we were doing all along.
-- Ward Cunningham


Ron Jeffries
 

Slava,

On Dec 6, 2019, at 2:47 PM, Slava Imeshev via Groups.Io <imeshev@...> wrote:

I stopped believing in team's self-organization long ago. There are luminaries like XP founders. There are amazing individuals who can do it and and I worked with them.  Those usually make up 5-10% of them team. The rest requires couching, education, encouragement, pushing forward and yes, imposing and enforcing best practices because were are paid for getting stuff done in time and with quality. Without imposing, as harsh as this word can be, teams descent to run-as-they can 80 hour weeks... 

I strongly disagree with imposing practices. There are no "best practices" and none of the practices we currently support are appropriate 100% of the time anywhere.

Coaching, education, encouragement ... those are good things. Imposing practices ... I'm sure we can do better than that.

Ron Jeffries
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana


Ron Jeffries
 

Robin,

On Dec 6, 2019, at 2:59 PM, R Dymond <rdymond@...> wrote:

I was shocked when I heard the devs chose to abandon disciplines that had helped to save the business. It took them 3 years to mature to a point where they recognized the value of CI. I doubt they do tdd. Since that time I have been involved with many Agile transitions and seen the same patterns in adopting Scrum and Agile.

I think it does happen, usually when there's pressure from above. It's too easy to fall into the feeling that we can go faster by skipping the tests. And, for a brief while, if the code doesn't have to work all the time, we can. 

Mandating the practices, with pressure on, will just result in TDD with no assertions. Any metric can and will be gamed, especially under pressure.

Ron Jeffries
Speed is ppoor subsittute fo accurancy -- Fortune Cookie


Eb Alson
 

You can't stop believing in team self-organization because a team will ALWAYS self-organize in some manner. They might not organize in a way that gives you the results you need. Sure that's possible. Your response to that is one of several approaches which obviously includes mandating/imposing certain practices ala factory workers at the dawn of scientific management.


On Fri, Dec 6, 2019 at 2:49 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
Imposing best practices may be needed to get things done. For example:

- The quality may not be where it should be. Add unit testing and TDD.
- The team is overworked. Add planning game.
- Projects are late. Add CI.

Etc...

I stopped believing in team's self-organization long ago. There are luminaries like XP founders. There are amazing individuals who can do it and and I worked with them.  Those usually make up 5-10% of them team. The rest requires couching, education, encouragement, pushing forward and yes, imposing and enforcing best practices because were are paid for getting stuff done in time and with quality. Without imposing, as harsh as this word can be, teams descent to run-as-they can 80 hour weeks... 

Slava


R Dymond
 

Yes, hope my story conveyed that.

I am most successful at helping others when they want my help. Sometimes it takes spending time together to understand each other. I am least successful when people for whatever reason, are unable to hear my ideas. It may be that they were mandated to attend a training or receive coaching, or it may be that they feel none of the changes I am bringing are in their best interests. These days I focus on those who want the help and take a pass on those who are going through the motions to please others.

I long ago discovered that having an answer was about 20% of the effort. Getting others to agree with that answer is the other 80%.


Robin Dymond CST
Managing Partner
Innovel
p:1 804 239 4329
w:www.innovel.net
 



On Fri, Dec 6, 2019 at 2:04 PM Ron Jeffries <ronjeffriesacm@...> wrote:
It is my view that mandating any practice is directly counter both to the Scrum Guide and to the Manifesto.

Scrum Guide says that the team decides how to do the work. Manifesto says self-organization about 93 times.

Mandate results, not method.

On Dec 6, 2019, at 2:43 PM, R Dymond <rdymond@...> wrote:

Agreed James. I would be much more comfortable mandating test automation, otherwise as you said a lot of cost for manual work is incurred... and isnt the business reason for software development often about eliminating manual tedious work with automation?

Also comfortable mandating Agile since it lowers the risk of loss in product development.

I would rather have people build their skills in a way that mixes curiosity and mentorship. Having a culture of encouragement and leadership that values these ideas seems a better way to engage the interested. This is where celebrity devs could increase broad interest.


Ron Jeffries
It was important to me that we accumulate the learnings about the application over time by modifying the program to look as if we had known what we were doing all along.
-- Ward Cunningham


Slava Imeshev <imeshev@...>
 

I wish the reality connected with that. Like I said in a separate thread, there are teams that can self organize. I've seen it two or three of times. The didn't / doesn't.  There is a multitude of reasons why. It's really a people problem.

On Friday, December 6, 2019, 12:04:14 PM PST, Ron Jeffries <ronjeffriesacm@...> wrote:


It is my view that mandating any practice is directly counter both to the Scrum Guide and to the Manifesto.

Scrum Guide says that the team decides how to do the work. Manifesto says self-organization about 93 times.

Mandate results, not method.

On Dec 6, 2019, at 2:43 PM, R Dymond <rdymond@...> wrote:

Agreed James. I would be much more comfortable mandating test automation, otherwise as you said a lot of cost for manual work is incurred... and isnt the business reason for software development often about eliminating manual tedious work with automation?

Also comfortable mandating Agile since it lowers the risk of loss in product development.

I would rather have people build their skills in a way that mixes curiosity and mentorship. Having a culture of encouragement and leadership that values these ideas seems a better way to engage the interested. This is where celebrity devs could increase broad interest.


Ron Jeffries
It was important to me that we accumulate the learnings about the application over time by modifying the program to look as if we had known what we were doing all along.
-- Ward Cunningham


JeffGrigg
 

There's a lot to be said for teaching one's employees the skills and knowledge you require them to have. And something to be said for hiring people who have these skills, or are at least open to learning them.


And I used to be that good at pool -- only bank shots allowed.   ;->


On Fri, Dec 6, 2019 at 1:11 PM James Grenning <james@...> wrote:
Mandating TDD would be like mandating that all shots in pool be bank shots.  Unless someone had the skill in bank shots,  not many balks will be pocketed. 

TDD and bank shots require skill to execute.  Skills take time to learn. 

Mandating test automation is a business decision, as the cost of manual retest is so high. There are skills to learn here too, though maybe less difficult to get started. 

James

...


David Kramer
 

(Hey, new list member, been lurking for a few weeks to get a feel for it.  Software Engineering Manager and Agile Coach currently looking for opportunities for either role, on the Board of https://agilenewengland.org )

Part of the "people problem" with this stuff is that as is clear from society as a whole, people don't always act in their best interest, and/or don't strive for the same goals we would in their shoes.

Having worked at several companies that were trying to break free of "small company ways of doing things" and trying to drive Agile transformations, better software development practices, and empowered teams, I see a lot of push-back from the very people that hire me, let alone the developers.  As much as they wanted to benefit from Agile, they didn't want to give up control.  They could not give up micromanaging.  It was more important for them to be in control than it was for the company to be successful. 

One company I worked with, I had done a lot of work on empowering teams, establishing release strategies, branching strategies, continuous builds, etc.   Before I got there the devs had no say in what stories went into the sprint, and there was no story grooming, so they would often take multiple sprints to complete, and "done" work would sit weeks or longer before ending up in a release.  We made great strides, gave the development team the power to push back on stories that weren't ready, got stuff tested earlier and more thoroughly, had more successful releases, and employee satisfaction improved immensely.  I needed to go out on medical leave for a while, and when I came back, every single practice I had introduced got rolled back, with expected results.

With the developers, it is somewhat easier to talk to them about the benefits to them that these practices offer.  With upper management, there seems to be a lot more in play than listing costs and benefits.

On 12/6/19 2:59 PM, R Dymond wrote:
Been there, done that (sorta).

 In a startup with a junior crew, had every dev pair with a TW consultant to learn TDD and CI. It was 2002 and we were the first outside thoughtworks to use CC.net. we ran with cc.net and some devs doing tdd some not. Ran that way for a year.

Then they lost their investor and downsized, I left. After I left the remaining team abandoned tdd (except one infected dev), and soon after turned off cc.net. Eventually, they did choose to revive cc.net, 3 years later.

I was shocked when I heard the devs chose to abandon disciplines that had helped to save the business. It took them 3 years to mature to a point where they recognized the value of CI. I doubt they do tdd. Since that time I have been involved with many Agile transitions and seen the same patterns in adopting Scrum and Agile.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 12:43 PM Ron Jeffries <ronjeffriesacm@...> wrote:
In my view this should never, ever, be done:

On Dec 6, 2019, at 12:03 PM, Eb Alson <amaeze@...> wrote:

Imposing at the right altitude is critical then because “Using XP or doing TDD“ can also be the goal/standard  that a CTO sets.


Ron Jeffries
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg


Eb Alson
 

self-organization is ongoing otherwise entropy occurs.


On Fri, Dec 6, 2019 at 3:58 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
I wish the reality connected with that. Like I said in a separate thread, there are teams that can self organize. I've seen it two or three of times. The didn't / doesn't.  There is a multitude of reasons why. It's really a people problem.

On Friday, December 6, 2019, 12:04:14 PM PST, Ron Jeffries <ronjeffriesacm@...> wrote:




Eb Alson
 

Teaching only goes so far. 

"You can only tell, if it is a request or a demand, by how I treat you, if you don't do it." Non-Violent Communication , Marshal B. Rosenberg

You can teach all day but if you don't mandate then it's optional. The entire team could decide post-teaching they want to do it. Maybe.

On Fri, Dec 6, 2019 at 4:54 PM JeffGrigg <jeffreytoddgrigg@...> wrote:
There's a lot to be said for teaching one's employees the skills and knowledge you require them to have. And something to be said for hiring people who have these skills, or are at least open to learning them.


And I used to be that good at pool -- only bank shots allowed.   ;->


On Fri, Dec 6, 2019 at 1:11 PM James Grenning <james@...> wrote:
Mandating TDD would be like mandating that all shots in pool be bank shots.  Unless someone had the skill in bank shots,  not many balks will be pocketed. 

TDD and bank shots require skill to execute.  Skills take time to learn. 

Mandating test automation is a business decision, as the cost of manual retest is so high. There are skills to learn here too, though maybe less difficult to get started. 

James

...




Jim Shore
 

When I think about the companies that I’ve seen be most successful with Agile and XP, this is how they did it.

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: http://jamesshore.com

On Dec 7, 2019, at 4:22 AM, JeffGrigg <jeffreytoddgrigg@...> wrote:

Something I've seen that was quite successful ...
1. During the hiring process, the company made it quite clear that Extreme Programming, including Pair Programming and the other practices was mandatory.
2. In the team's room, there are half as many machines as developers. "You work it out." says the boss.  (And you're kind of strongly expected to do "pair programming" of some kind. And if people quit, an appropriate number of machines will be removed.)

Actually...  It worked quite well.

The teams were enabled and empowered to change the process as they saw fit.  ... within "reasonable" bounds.

Some did kanban boards.  Some did big visible charts.  Some had timers to signal pair switching.

People knew before being hired what they were signing up for.  And then we did it.


Slava Imeshev <imeshev@...>
 

David,

This is my observation is well and the question of how to make changes stick really bugs me.

Slava

On Friday, December 6, 2019, 1:54:11 PM PST, David Kramer <david@...> wrote:


(Hey, new list member, been lurking for a few weeks to get a feel for it.  Software Engineering Manager and Agile Coach currently looking for opportunities for either role, on the Board of https://agilenewengland.org )

Part of the "people problem" with this stuff is that as is clear from society as a whole, people don't always act in their best interest, and/or don't strive for the same goals we would in their shoes.

Having worked at several companies that were trying to break free of "small company ways of doing things" and trying to drive Agile transformations, better software development practices, and empowered teams, I see a lot of push-back from the very people that hire me, let alone the developers.  As much as they wanted to benefit from Agile, they didn't want to give up control.  They could not give up micromanaging.  It was more important for them to be in control than it was for the company to be successful. 

One company I worked with, I had done a lot of work on empowering teams, establishing release strategies, branching strategies, continuous builds, etc.   Before I got there the devs had no say in what stories went into the sprint, and there was no story grooming, so they would often take multiple sprints to complete, and "done" work would sit weeks or longer before ending up in a release.  We made great strides, gave the development team the power to push back on stories that weren't ready, got stuff tested earlier and more thoroughly, had more successful releases, and employee satisfaction improved immensely.  I needed to go out on medical leave for a while, and when I came back, every single practice I had introduced got rolled back, with expected results.

With the developers, it is somewhat easier to talk to them about the benefits to them that these practices offer.  With upper management, there seems to be a lot more in play than listing costs and benefits.

On 12/6/19 2:59 PM, R Dymond wrote:
Been there, done that (sorta).

 In a startup with a junior crew, had every dev pair with a TW consultant to learn TDD and CI. It was 2002 and we were the first outside thoughtworks to use CC.net. we ran with cc.net and some devs doing tdd some not. Ran that way for a year.

Then they lost their investor and downsized, I left. After I left the remaining team abandoned tdd (except one infected dev), and soon after turned off cc.net. Eventually, they did choose to revive cc.net, 3 years later.

I was shocked when I heard the devs chose to abandon disciplines that had helped to save the business. It took them 3 years to mature to a point where they recognized the value of CI. I doubt they do tdd. Since that time I have been involved with many Agile transitions and seen the same patterns in adopting Scrum and Agile.

Robin Dymond, CST
Managing Partner, Innovel
www.innovel.net
www.scrumtraining.com
Direct: (804) 239-4329
twitter: @robindymond
Linkedin: https://www.linkedin.com/in/robindymond

On Fri, Dec 6, 2019, 12:43 PM Ron Jeffries <ronjeffriesacm@...> wrote:
In my view this should never, ever, be done:

On Dec 6, 2019, at 12:03 PM, Eb Alson <amaeze@...> wrote:

Imposing at the right altitude is critical then because “Using XP or doing TDD“ can also be the goal/standard  that a CTO sets.


Ron Jeffries
There's no word for accountability in Finnish. 
Accountability is something that is left when responsibility has been subtracted. 
--Pasi Sahlberg


R Dymond
 

Back to JB's (Hi JB!) original question:

For me I think a lot has changed, some of which this question has pointed out.

I think things were a bit more simple in some respects in 2002-2003 because I didn't have much experience with these ideas.
I also have become educated on the difficulty of changing minds and organizations.
VHS vs Beta, Windows vs MacOS, and now SAFe vs LeSS. Better marketing and weaker product tends to beat better product with weaker marketing. As an engineer I think this sucks, but there have been far too many examples to deny it, and it is independent of field or technology. It still sucks to be on the losing side with the better ideas.
I am surprised at how fast cloud adoption is moving. Companies with 30 year old tech stacks are investing hundreds of millions to get off the old stuff and migrate to the cloud. This seems like a huge opportunity to change *how* people code, so I think there should be a real sense of urgency to grow TDD adoption. However we face the same dilemma: Does the developer take limited time to learn TDD or Kubernetes? Do they learn TDD or GO? One is recognized by employers and gets them a higher paying job and one doesn't.

Perhaps XP should be renamed Cloud Craft and the sponsor is the Cloud Craft Guild. There ya go, only took an old fashioned and some wine to get the name game going.

Cheers,
Robin.



On Fri, Dec 6, 2019 at 3:26 PM Eb Alson <amaeze@...> wrote:
Teaching only goes so far. 

"You can only tell, if it is a request or a demand, by how I treat you, if you don't do it." Non-Violent Communication , Marshal B. Rosenberg

You can teach all day but if you don't mandate then it's optional. The entire team could decide post-teaching they want to do it. Maybe.

On Fri, Dec 6, 2019 at 4:54 PM JeffGrigg <jeffreytoddgrigg@...> wrote:
There's a lot to be said for teaching one's employees the skills and knowledge you require them to have. And something to be said for hiring people who have these skills, or are at least open to learning them.


And I used to be that good at pool -- only bank shots allowed.   ;->


On Fri, Dec 6, 2019 at 1:11 PM James Grenning <james@...> wrote:
Mandating TDD would be like mandating that all shots in pool be bank shots.  Unless someone had the skill in bank shots,  not many balks will be pocketed. 

TDD and bank shots require skill to execute.  Skills take time to learn. 

Mandating test automation is a business decision, as the cost of manual retest is so high. There are skills to learn here too, though maybe less difficult to get started. 

James

...



--


Tim Ottinger
 

Aggro much? 

I think that there is no reason that people who aren’t pro-certification aren’t innovators in plenty of areas. Case in point: the original XP people.  I don’t think I’ve seen an XP certification, so there are no innovators there? Do certifications cause innovation or prevent it? 

Now, that said, none of us gets to choose who the innovators are in the world. You can expect whatever you want, as long as you don’t blame the world for not meeting your expectations.

J. Holmes is well respected for his teaching, thinking, writing. I don’t think we need to rag on him or his views here. 


On Wednesday, December 4, 2019, 19:03, R Dymond <rdymond@...> wrote:

Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.

Regards 
Robin

On Wed, Dec 4, 2019, 5:44 PM <james.holmes@...> wrote:
I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."

I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.


Steve Gordon
 

In the case of SAFe and LeSS, the product does really provide greater management control,.  No matter how well you market XP or TDD, they do transfer more control from management to the "talent" and the decision makers see that clearly.


On Fri, Dec 6, 2019 at 6:51 PM R Dymond <rdymond@...> wrote:
Back to JB's (Hi JB!) original question:

For me I think a lot has changed, some of which this question has pointed out.

I think things were a bit more simple in some respects in 2002-2003 because I didn't have much experience with these ideas.
I also have become educated on the difficulty of changing minds and organizations.
VHS vs Beta, Windows vs MacOS, and now SAFe vs LeSS. Better marketing and weaker product tends to beat better product with weaker marketing. As an engineer I think this sucks, but there have been far too many examples to deny it, and it is independent of field or technology. It still sucks to be on the losing side with the better ideas.
I am surprised at how fast cloud adoption is moving. Companies with 30 year old tech stacks are investing hundreds of millions to get off the old stuff and migrate to the cloud. This seems like a huge opportunity to change *how* people code, so I think there should be a real sense of urgency to grow TDD adoption. However we face the same dilemma: Does the developer take limited time to learn TDD or Kubernetes? Do they learn TDD or GO? One is recognized by employers and gets them a higher paying job and one doesn't.

Perhaps XP should be renamed Cloud Craft and the sponsor is the Cloud Craft Guild. There ya go, only took an old fashioned and some wine to get the name game going.

Cheers,
Robin.



On Fri, Dec 6, 2019 at 3:26 PM Eb Alson <amaeze@...> wrote:
Teaching only goes so far. 

"You can only tell, if it is a request or a demand, by how I treat you, if you don't do it." Non-Violent Communication , Marshal B. Rosenberg

You can teach all day but if you don't mandate then it's optional. The entire team could decide post-teaching they want to do it. Maybe.

On Fri, Dec 6, 2019 at 4:54 PM JeffGrigg <jeffreytoddgrigg@...> wrote:
There's a lot to be said for teaching one's employees the skills and knowledge you require them to have. And something to be said for hiring people who have these skills, or are at least open to learning them.


And I used to be that good at pool -- only bank shots allowed.   ;->


On Fri, Dec 6, 2019 at 1:11 PM James Grenning <james@...> wrote:
Mandating TDD would be like mandating that all shots in pool be bank shots.  Unless someone had the skill in bank shots,  not many balks will be pocketed. 

TDD and bank shots require skill to execute.  Skills take time to learn. 

Mandating test automation is a business decision, as the cost of manual retest is so high. There are skills to learn here too, though maybe less difficult to get started. 

James

...



--


Phil Goodwin
 

Sometimes it pays to not fight fire with fire. Things that are not well said are perhaps still worth saying. 

I think there's an interesting tension here. At the root are the patterns of dysfunction that pop up in the way people organize themselves to get work done. As a broad generalization we can try to get rid of the dysfunction by finding a better way and selling it, or we can meet the organizations we encounter where they are and whittle away at the dysfunction one behavior at a time. 

When I read Robin's post I'm reminded of the times we've tried to bring XP into an organization whose developers understood it well and were clear about not wanting it. One of the big problems I've encountered while fighting dysfunction is that dysfunction is not the same as non-function. Dysfunctional systems work. They just work in a way that is unpleasant or otherwise sub-optimal (usually by indirectly fulfilling needs that someone feels shame about). If you try to fix the dysfunction without fulfilling the unstated need the system will start pushing your changes right back out. 

James is right to be suspicious of any methodology that sells easily because transformative change is always uncomfortable (or else you'd already be doing it) and discomfort doesn't sell. I hear Robin making a different point, which is that we need to meet our teams in the condition where we find them and understand that they may be optimizing for different values than we are. James is warning us away from accepting superficial changes that don't address the underlying issues. Robin is saying that we shouldn't be so stuck on our own values that we lose sight of what our customers are valuing. I think there's some common ground to be found in recognizing the need to dig into the needs and beliefs that drive the behaviors of the teams we're leading in order to improve the way they operate. When we do that we'll run into our own ideas about what is optimal and often find that they are in conflict with the other leadership around us. It's in the process of resolving those conflicts that real improvements will come. 

And it's the process of resolution, not the resolution itself, that brings about meaningful change. If the process unfolds in an honest and vulnerable way the results will work if they are at all practical. If it doesn't no amount of formal structure will save the team from itself.


On Fri, Dec 6, 2019, 6:34 PM Tim Ottinger via Groups.Io <linux_tim=yahoo.com@groups.io> wrote:
Aggro much? 

I think that there is no reason that people who aren’t pro-certification aren’t innovators in plenty of areas. Case in point: the original XP people.  I don’t think I’ve seen an XP certification, so there are no innovators there? Do certifications cause innovation or prevent it? 

Now, that said, none of us gets to choose who the innovators are in the world. You can expect whatever you want, as long as you don’t blame the world for not meeting your expectations.

J. Holmes is well respected for his teaching, thinking, writing. I don’t think we need to rag on him or his views here. 



Sent from Yahoo Mail for iPad

On Wednesday, December 4, 2019, 19:03, R Dymond <rdymond@...> wrote:

Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.

Regards 
Robin

On Wed, Dec 4, 2019, 5:44 PM <james.holmes@...> wrote:
I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."

I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.


Larry Brunelle
 

Thanks for an interesting and enlightening parsing and distilling of
wisdom found in some posts by others. Humans (often regrettably) are
motivated, and behave, well, like humans, and failure to recognize
the same can get us bit pretty good.

Phil Goodwin wrote:

Sometimes it pays to not fight fire with fire. Things that are not well said are perhaps still worth saying.
I think there's an interesting tension here. At the root are the patterns of dysfunction that pop up in the way people organize themselves to get work done. As a broad generalization we can try to get rid of the dysfunction by finding a better way and selling it, or we can meet the organizations we encounter where they are and whittle away at the dysfunction one behavior at a time.
When I read Robin's post I'm reminded of the times we've tried to bring XP into an organization whose developers understood it well and were clear about not wanting it. One of the big problems I've encountered while fighting dysfunction is that dysfunction is not the same as non-function. Dysfunctional systems work. They just work in a way that is unpleasant or otherwise sub-optimal (usually by indirectly fulfilling needs that someone feels shame about). If you try to fix the dysfunction without fulfilling the unstated need the system will start pushing your changes right back out.
James is right to be suspicious of any methodology that sells easily because transformative change is always uncomfortable (or else you'd already be doing it) and discomfort doesn't sell. I hear Robin making a different point, which is that we need to meet our teams in the condition where we find them and understand that they may be optimizing for different values than we are. James is warning us away from accepting superficial changes that don't address the underlying issues. Robin is saying that we shouldn't be so stuck on our own values that we lose sight of what our customers are valuing. I think there's some common ground to be found in recognizing the need to dig into the needs and beliefs that drive the behaviors of the teams we're leading in order to improve the way they operate. When we do that we'll run into our own ideas about what is optimal and often find that they are in conflict with the other leadership around us. It's in the process of resolving those conflicts that real improvements will come.
And it's the process of resolution, not the resolution itself, that brings about meaningful change. If the process unfolds in an honest and vulnerable way the results will work if they are at all practical. If it doesn't no amount of formal structure will save the team from itself.
On Fri, Dec 6, 2019, 6:34 PM Tim Ottinger via Groups.Io <linux_tim=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
Aggro much?
I think that there is no reason that people who aren’t pro-certification aren’t innovators in plenty of areas. Case in point: the original XP people.  I don’t think I’ve seen an XP certification, so there are no innovators there? Do certifications cause innovation or prevent it?
Now, that said, none of us gets to choose who the innovators are in the world. You can expect whatever you want, as long as you don’t blame the world for not meeting your expectations.
J. Holmes is well respected for his teaching, thinking, writing. I don’t think we need to rag on him or his views here.
Sent from Yahoo Mail for iPad <https://overview.mail.yahoo.com/?.src=iOS>
On Wednesday, December 4, 2019, 19:03, R Dymond <rdymond@innovel.net <mailto:rdymond@innovel.net>> wrote:
Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.
Regards
Robin
On Wed, Dec 4, 2019, 5:44 PM <james.holmes@gmail.com <mailto:james.holmes@gmail.com>> wrote:
I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."
I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.


Avi Kessner
 

I had an idea the other night. It's both really silly but also maybe good, and mybe it's been tried before.

I was thinking about the principles of TDD and how it fits into XP in general.

What if before committing to the practices, a developer had a way of gaining feedback that they are capable of implementing the practices. I.e. a test, a self assessment test.

Take this test, and if you score well, you can have confirmation/confidence that you can engage in X practice safely.

On Sun, Dec 8, 2019, 05:58 Larry Brunelle <brunelle@...> wrote:

Thanks for an interesting and enlightening parsing and distilling of
wisdom found in some posts by others.  Humans (often regrettably) are
motivated, and behave, well, like humans, and failure to recognize
the same can get us bit pretty good.

Phil Goodwin wrote:
> Sometimes it pays to not fight fire with fire. Things that are not well said are perhaps still worth saying.
>
> I think there's an interesting tension here. At the root are the patterns of dysfunction that pop up in the way people organize themselves to get work done. As a broad generalization we can try to get rid of the dysfunction by finding a better way and selling it, or we can meet the organizations we encounter where they are and whittle away at the dysfunction one behavior at a time.
>
> When I read Robin's post I'm reminded of the times we've tried to bring XP into an organization whose developers understood it well and were clear about not wanting it. One of the big problems I've encountered while fighting dysfunction is that dysfunction is not the same as non-function. Dysfunctional systems work. They just work in a way that is unpleasant or otherwise sub-optimal (usually by indirectly fulfilling needs that someone feels shame about). If you try to fix the dysfunction without fulfilling the unstated need the system will start pushing your changes right back out.
>
> James is right to be suspicious of any methodology that sells easily because transformative change is always uncomfortable (or else you'd already be doing it) and discomfort doesn't sell. I hear Robin making a different point, which is that we need to meet our teams in the condition where we find them and understand that they may be optimizing for different values than we are. James is warning us away from accepting superficial changes that don't address the underlying issues. Robin is saying that we shouldn't be so stuck on our own values that we lose sight of what our customers are valuing. I think there's some common ground to be found in recognizing the need to dig into the needs and beliefs that drive the behaviors of the teams we're leading in order to improve the way they operate. When we do that we'll run into our own ideas about what is optimal and often find that they are in conflict with the other leadership around us. It's in the process of resolving those
> conflicts that real improvements will come.
>
> And it's the process of resolution, not the resolution itself, that brings about meaningful change. If the process unfolds in an honest and vulnerable way the results will work if they are at all practical. If it doesn't no amount of formal structure will save the team from itself.
>
> On Fri, Dec 6, 2019, 6:34 PM Tim Ottinger via Groups.Io <linux_tim=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
>
>     Aggro much?
>
>     I think that there is no reason that people who aren’t pro-certification aren’t innovators in plenty of areas. Case in point: the original XP people.  I don’t think I’ve seen an XP certification, so there are no innovators there? Do certifications cause innovation or prevent it?
>
>     Now, that said, none of us gets to choose who the innovators are in the world. You can expect whatever you want, as long as you don’t blame the world for not meeting your expectations.
>
>     J. Holmes is well respected for his teaching, thinking, writing. I don’t think we need to rag on him or his views here.
>
>
>
>     Sent from Yahoo Mail for iPad <https://overview.mail.yahoo.com/?.src=iOS>
>
>     On Wednesday, December 4, 2019, 19:03, R Dymond <rdymond@... <mailto:rdymond@...>> wrote:
>
>         Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.
>
>         Regards
>         Robin
>
>         On Wed, Dec 4, 2019, 5:44 PM <james.holmes@... <mailto:james.holmes@...>> wrote:
>
>             I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."
>
>             I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.
>
>





James Holmes
 

Ah, I see I have probably been mistaken for a more prolific, nicer James Holmes. I'm the snarky Australian one who writes code for a living and sometimes teaches people TDD when they're interested enough.


On Sat, 7 Dec 2019, 13:34 Tim Ottinger via Groups.Io, <linux_tim=yahoo.com@groups.io> wrote:


J. Holmes is well respected for his teaching, thinking, writing. I don’t think we need to rag on him or his views here. 


Ron Jeffries
 

i think that would be useful, and consistent, perhaps, with agile alliance's notions on certification

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@acm.org is a better address for me, maybe.

On Dec 7, 2019, at 10:58 PM, Larry Brunelle <brunelle@ieee.org> wrote:


Thanks for an interesting and enlightening parsing and distilling of
wisdom found in some posts by others. Humans (often regrettably) are
motivated, and behave, well, like humans, and failure to recognize
the same can get us bit pretty good.

Phil Goodwin wrote:
Sometimes it pays to not fight fire with fire. Things that are not well said are perhaps still worth saying.
I think there's an interesting tension here. At the root are the patterns of dysfunction that pop up in the way people organize themselves to get work done. As a broad generalization we can try to get rid of the dysfunction by finding a better way and selling it, or we can meet the organizations we encounter where they are and whittle away at the dysfunction one behavior at a time.
When I read Robin's post I'm reminded of the times we've tried to bring XP into an organization whose developers understood it well and were clear about not wanting it. One of the big problems I've encountered while fighting dysfunction is that dysfunction is not the same as non-function. Dysfunctional systems work. They just work in a way that is unpleasant or otherwise sub-optimal (usually by indirectly fulfilling needs that someone feels shame about). If you try to fix the dysfunction without fulfilling the unstated need the system will start pushing your changes right back out.
James is right to be suspicious of any methodology that sells easily because transformative change is always uncomfortable (or else you'd already be doing it) and discomfort doesn't sell. I hear Robin making a different point, which is that we need to meet our teams in the condition where we find them and understand that they may be optimizing for different values than we are. James is warning us away from accepting superficial changes that don't address the underlying issues. Robin is saying that we shouldn't be so stuck on our own values that we lose sight of what our customers are valuing. I think there's some common ground to be found in recognizing the need to dig into the needs and beliefs that drive the behaviors of the teams we're leading in order to improve the way they operate. When we do that we'll run into our own ideas about what is optimal and often find that they are in conflict with the other leadership around us. It's in the process of resolving those conflicts that real improvements will come.
And it's the process of resolution, not the resolution itself, that brings about meaningful change. If the process unfolds in an honest and vulnerable way the results will work if they are at all practical. If it doesn't no amount of formal structure will save the team from itself.
On Fri, Dec 6, 2019, 6:34 PM Tim Ottinger via Groups.Io <linux_tim=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
Aggro much?
I think that there is no reason that people who aren’t pro-certification aren’t innovators in plenty of areas. Case in point: the original XP people. I don’t think I’ve seen an XP certification, so there are no innovators there? Do certifications cause innovation or prevent it?
Now, that said, none of us gets to choose who the innovators are in the world. You can expect whatever you want, as long as you don’t blame the world for not meeting your expectations.
J. Holmes is well respected for his teaching, thinking, writing. I don’t think we need to rag on him or his views here.
Sent from Yahoo Mail for iPad <https://overview.mail.yahoo.com/?.src=iOS>
On Wednesday, December 4, 2019, 19:03, R Dymond <rdymond@innovel.net <mailto:rdymond@innovel.net>> wrote:
Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.
Regards
Robin
On Wed, Dec 4, 2019, 5:44 PM <james.holmes@gmail.com <mailto:james.holmes@gmail.com>> wrote:
I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."
I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.



Slava Imeshev <imeshev@...>
 

Yes! I often ask to write Integer.toString(int) during interviews, starting with a test. Usually, the responses are:

* Huh?
* Hmm...
* That’s easy!

Slava

On Dec 7, 2019, at 11:25 PM, Avi Kessner <akessner@...> wrote:

I had an idea the other night. It's both really silly but also maybe good, and mybe it's been tried before.

I was thinking about the principles of TDD and how it fits into XP in general.

What if before committing to the practices, a developer had a way of gaining feedback that they are capable of implementing the practices. I.e. a test, a self assessment test.

Take this test, and if you score well, you can have confirmation/confidence that you can engage in X practice safely.

On Sun, Dec 8, 2019, 05:58 Larry Brunelle <brunelle@...> wrote:

Thanks for an interesting and enlightening parsing and distilling of
wisdom found in some posts by others.  Humans (often regrettably) are
motivated, and behave, well, like humans, and failure to recognize
the same can get us bit pretty good.

Phil Goodwin wrote:
> Sometimes it pays to not fight fire with fire. Things that are not well said are perhaps still worth saying.
>
> I think there's an interesting tension here. At the root are the patterns of dysfunction that pop up in the way people organize themselves to get work done. As a broad generalization we can try to get rid of the dysfunction by finding a better way and selling it, or we can meet the organizations we encounter where they are and whittle away at the dysfunction one behavior at a time.
>
> When I read Robin's post I'm reminded of the times we've tried to bring XP into an organization whose developers understood it well and were clear about not wanting it. One of the big problems I've encountered while fighting dysfunction is that dysfunction is not the same as non-function. Dysfunctional systems work. They just work in a way that is unpleasant or otherwise sub-optimal (usually by indirectly fulfilling needs that someone feels shame about). If you try to fix the dysfunction without fulfilling the unstated need the system will start pushing your changes right back out.
>
> James is right to be suspicious of any methodology that sells easily because transformative change is always uncomfortable (or else you'd already be doing it) and discomfort doesn't sell. I hear Robin making a different point, which is that we need to meet our teams in the condition where we find them and understand that they may be optimizing for different values than we are. James is warning us away from accepting superficial changes that don't address the underlying issues. Robin is saying that we shouldn't be so stuck on our own values that we lose sight of what our customers are valuing. I think there's some common ground to be found in recognizing the need to dig into the needs and beliefs that drive the behaviors of the teams we're leading in order to improve the way they operate. When we do that we'll run into our own ideas about what is optimal and often find that they are in conflict with the other leadership around us. It's in the process of resolving those
> conflicts that real improvements will come.
>
> And it's the process of resolution, not the resolution itself, that brings about meaningful change. If the process unfolds in an honest and vulnerable way the results will work if they are at all practical. If it doesn't no amount of formal structure will save the team from itself.
>
> On Fri, Dec 6, 2019, 6:34 PM Tim Ottinger via Groups.Io <linux_tim=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:
>
>     Aggro much?
>
>     I think that there is no reason that people who aren’t pro-certification aren’t innovators in plenty of areas. Case in point: the original XP people.  I don’t think I’ve seen an XP certification, so there are no innovators there? Do certifications cause innovation or prevent it?
>
>     Now, that said, none of us gets to choose who the innovators are in the world. You can expect whatever you want, as long as you don’t blame the world for not meeting your expectations.
>
>     J. Holmes is well respected for his teaching, thinking, writing. I don’t think we need to rag on him or his views here.
>
>
>
>     Sent from Yahoo Mail for iPad <https://overview.mail.yahoo.com/?.src=iOS>
>
>     On Wednesday, December 4, 2019, 19:03, R Dymond <rdymond@... <mailto:rdymond@...>> wrote:
>
>         Great. So we will not expect any innovation from you. That's OK. It took me a while to realize that Extreme Positions don't really do anything except reflect on me. Calling things broken doesn't fix it. Waiting for others to change means everything is out of my control, and that is handy if I want to criticize, and it absolves me of any responsibility. These days I prefer to act, to have empathy, to recognize that people have succeeded without many of the ideas we advocate. So we are not "right," we have a different approach that we think is better. Our CUSTOMERS by in large do not agree that it is better.
>
>         Regards
>         Robin
>
>         On Wed, Dec 4, 2019, 5:44 PM <james.holmes@... <mailto:james.holmes@...>> wrote:
>
>             I'm always fascinated by folks who look at the corrupt, burning garbage heap that is Scrum Certification and think, "I want that, but for development practices."
>
>             I'm increasingly of the opinion that XP remains useful precisely because it has not had the same popularity that Scrum has suffered. I'm likewise of the opinion that something that sells as well as Scrum in a market full of broken management systems and toxic workplaces is to be viewed with extreme suspicion.
>
>






Ron Jeffries
 

I would fail the quiz. I don't understand the question.

On Dec 10, 2019, at 12:26 AM, Slava Imeshev via Groups.Io <imeshev@...> wrote:

Yes! I often ask to write Integer.toString(int) during interviews, starting with a test. Usually, the responses are:

* Huh?
* Hmm...
* That’s easy!


Ron Jeffries
ronjeffries.com
Impossible is not a fact. It is an opinion.  -- Muhammad Ali




Dave Nicolette
 

Why would you ask something like that in an interview?


On Tue, Dec 10, 2019, 13:55 Ron Jeffries <ronjeffriesacm@...> wrote:
I would fail the quiz. I don't understand the question.

On Dec 10, 2019, at 12:26 AM, Slava Imeshev via Groups.Io <imeshev@...> wrote:

Yes! I often ask to write Integer.toString(int) during interviews, starting with a test. Usually, the responses are:

* Huh?
* Hmm...
* That’s easy!


Ron Jeffries
ronjeffries.com
Impossible is not a fact. It is an opinion.  -- Muhammad Ali




Ron Jeffries
 

I assume it is a quick testing coding question. I'm not sure how I feel about that kind of question, but it is a common thing to ask people to do some coding.

I might find it better to pair with them ...

R

On Dec 10, 2019, at 8:17 AM, Dave Nicolette <davenicolette@...> wrote:

Why would you ask something like that in an interview?


Ron Jeffries
Speed is ppoor subsittute fo accurancy -- Fortune Cookie


Avi Kessner
 

If anyone knows of any good self-assessment tests, I'll be happy to link to them. https://www.continuouscoding.org/resources/tests/
I myself have never seen one.
brought to you by the letters A, V, and I
and the number 47


On Tue, Dec 10, 2019 at 3:20 PM Ron Jeffries <ronjeffriesacm@...> wrote:
I assume it is a quick testing coding question. I'm not sure how I feel about that kind of question, but it is a common thing to ask people to do some coding.

I might find it better to pair with them ...

R

On Dec 10, 2019, at 8:17 AM, Dave Nicolette <davenicolette@...> wrote:

Why would you ask something like that in an interview?


Ron Jeffries
Speed is ppoor subsittute fo accurancy -- Fortune Cookie


Slava Imeshev <imeshev@...>
 

It’s a basic question. Checks if they can code and test / TDD.

Slava

On Dec 10, 2019, at 5:17 AM, Dave Nicolette <davenicolette@...> wrote:

Why would you ask something like that in an interview?

On Tue, Dec 10, 2019, 13:55 Ron Jeffries <ronjeffriesacm@...> wrote:
I would fail the quiz. I don't understand the question.

On Dec 10, 2019, at 12:26 AM, Slava Imeshev via Groups.Io <imeshev@...> wrote:

Yes! I often ask to write Integer.toString(int) during interviews, starting with a test. Usually, the responses are:

* Huh?
* Hmm...
* That’s easy!


Ron Jeffries
ronjeffries.com
Impossible is not a fact. It is an opinion.  -- Muhammad Ali







JeffGrigg
 

Yep.

And do they understand boundary conditions?

IE: Do they *TEST* them?



On Tue, Dec 10, 2019 at 12:08 PM Slava Imeshev via Groups.Io <imeshev=yahoo.com@groups.io> wrote:
It’s a basic question. Checks if they can code and test / TDD.

Slava

On Dec 10, 2019, at 5:17 AM, Dave Nicolette <davenicolette@...> wrote:

Why would you ask something like that in an interview?

On Tue, Dec 10, 2019, 13:55 Ron Jeffries <ronjeffriesacm@...> wrote:
I would fail the quiz. I don't understand the question.

On Dec 10, 2019, at 12:26 AM, Slava Imeshev via Groups.Io <imeshev@...> wrote:

Yes! I often ask to write Integer.toString(int) during interviews, starting with a test. Usually, the responses are:

* Huh?
* Hmm...
* That’s easy!


Ron Jeffries
ronjeffries.com
Impossible is not a fact. It is an opinion.  -- Muhammad Ali







John Welty
 

<<If they are just doing what they are told, then whoever is telling them what to do is ultimately responsible, so learning and improvement peters out really quickly.>>

I've seen this with programmers and in other disciplines too. I have fought hard against that attempted form of management on occasion. I have also lobbied somewhat unsuccessfully against it on behalf of others.

Many people want to feel part of the outcome. They want to see something and say, "That thing right there is better because of something I suggested or chose to do." not just, "I just did what I was told and anybody could've done it if they obeyed."

I prefer that we reason together about the best way to achieve desired outcomes. People who tell others what to do may just be doing that too. I notice a problem like that generally starts higher up the ladder. 


John Welty
 

I learned about Unit Testing when I wanted to learn about refactoring. I bought the Refactoring book and realized quite quickly I had something else to learn first. 
 
When I learned how to write software to test my software, I learned that I had a lot of working software that I no longer understood and could no longer easily gain an understanding of. I found long standing bugs that weren’t surfacing in operation but which must be causing hiccups at times. 
 
So my goal with TDD (new) and Test to verify a bug (for existing untested code) is to gain understanding and to clarify that gained understanding with well written tests. I can’t imagine investing software developer salaries in busywork (make the coverage tool show green). 
 
If it’s not advancing my understanding and capturing that understanding for my future self and others, it must be adding confusion to the code base and eroding developer confidence in making changes. Am I missing something?  
 
I’m still working on learning to think smaller when starting to approach a problem. I’m fortunate that most of my software is well contained; I don’t have other developers using it. I’ve been unfortunate that I’ve always worked alone and have only my own understanding of what authors mean when I read their books. 
 
I started making an investment in my own technical development late in 2018 by moving on from just reading books. I started buying some video courses that provided access to the author and stumbled upon the world of technical coaching. 
 
Starting on Monday I’ll no longer be coding solo. I have a new hire starting and I’m looking forward to put pairing and collaboration into practice. I’m quite eager to participate in any learning opportunities being facilitated by those who have substance. I’ve wasted way too much time learning from those who took it upon themselves to teach something they barely understand themselves. 
 


John Welty
 

<<All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.>>

 

Yes. This is what I’m trying to break free from and what I hope to spare those who join my team. I plan to leave things much better than I found them some day.

 

Best Regards,

 

John Welty

Welty Automation, Inc.

www.WeltyAutomation.com

(319) 389-4952

 

From: extremeprogramming@groups.io <extremeprogramming@groups.io> On Behalf Of Slava Imeshev via Groups.Io
Sent: Tuesday, December 3, 2019 12:43 PM
To: extremeprogramming@groups.io
Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?

 

George, thank you for raising the discussion to the top level.

 

Things that have changed for me over the past 20 years:

1. XP as a practice has been forgotten and many parts of it have fallen out of use.

 

2. I find myself continuously reinstalling [XP and Agile] best practices at the jobs I'm taking on. Continuous Integration, unit testing, refactoring, iterative development...

 

3. Teams are practicing either 'run as fast as you can' SDLC which is essentially a no-practice, or full blown waterfall, as in 'let's-plan-a-year-out' with all consequences.

 

4. Raise of the 'Product Manager' job which is a strange combo of a member of sales organization and a surrogate user. Engineers no longer can talk to users.

 

5. Use cases is not a thing anymore. Use cases were replaced with user stories that are short blurbs leading to ambiguity in implementation and testing and last moment changes in requirements.

 

6. Large scale projects. SW organizations can easily be in hundreds of people that ends up in a zoo of way of doing things unless top leadership pushes a particular approach down.

 

7. Code reviews now must which is great.

 

All in all, I feel that new entrants into the software development job are not educated in the engineering part of it. As a result the SDLC is largely defined by idiosyncrasies of the engineering leaders. Or teams self-organize and end up with no-process.

 

Slava

 

On Tuesday, December 3, 2019, 9:51:18 AM PST, George Paci <gpaci@...> wrote:

 

 

(This thread was buried in another thread; I'm trying to transplant it to the top level so it gets more exposure.)

Things that have changed for me over the past 20 years:

1) Nobody says "XP" or "Extreme Programming" anymore, even when they're doing many of the practices.

2) Developers didn't test 20 years ago. Now unit test suites are ubiquitous, and many of them are well-maintained.

3) Everybody's talking about User Stories, which were weird 20 years ago. Unfortunately, the tools have taken over the meaning, and I need to chant, "The card is a token for an ongoing conversation" over and over. Sometimes it gets through.

4) I no longer focus on the practices when I spread them; I just start using them when I pair with someone, and they catch on (or don't).  Maybe I should have specific sessions where I focus on, say, refactoring, or TDD.

There's probably more I've forgotten. 1999 was a long time ago.

--George

A lot of people mistake a short memory for a clear conscience.
    - Doug Larson

Subject:

Re: [extremeprogramming] What has changed for you over the past 20 years?

Date:

Tue, 29 Oct 2019 08:39:12 -0700

From:

Jay Bazuzi <jay@...>

Reply-To:

extremeprogramming@groups.io

To:

extremeprogramming@groups.io

 

From Arlo I heard a story that Corey Haines would experiment with doing a project without one of the practices that he normally relied on for success. He found that his defect rate was steadily decreasing over time, project to project, but when he skipped TDD his defect remained the same (he wasn't learning) and when he skipped Refactoring his defect rate went up (quality depends on design more than on tests).

 

That seems to match your experience, JB.

 

-J

 

On Tue, Oct 29, 2019 at 7:38 AM J. B. Rainsberger <jbrains762@...> wrote:

On Tue, Oct 29, 2019 at 3:16 PM Ken Auer <ken.auer@...> wrote:

Thanks, JB,

 

I was surprised.  Let's see what happens.  The timing is interesting as I was just recently prompted to dig out some old articles/papers I've written and have some reflective time to publish updates... what is timeless since the early 2000s and what has evolved (at least for me).

 

This leads to a wider discussion regarding what has changed for you as an XP enthusiast and practitioner over the years. I'd like to keep the question wide open, so don't hold back.

 

I recently experimented with evolutionary design without tests and I found it enjoyable and illuminating.

 

I worked with a group of 3 people. They wanted to practise microsteps and to see a design evolve. For 3 hours, I drove while they typed. They practised the microsteps inside their IDE (elementary refactorings, keystrokes) and we went through 2 features of one of my teaching examples, "test"-driven (meaning that we wrote and ran the tests in our heads). It worked surprisingly well! They got to see some simple design evolve (albeit with no pressure from tests) and that made them happy. They could more clearly _see_ the power of evolutionary design, related to being able to defer commitment and change directions as needs change. We also just went more quickly than we would have had we written the tests.

 

Of course, I told them that if we got into trouble, then we'd start writing tests. Fortunately, we didn't get into trouble in just 3 hours. :)

 

So it turns out that after a decade or two of practise, one can live without the tests a surprising amount---at least in some contexts.

--


Stephen Dicks
 

Where did the top quote come from? It resonates pretty well with what I have seen over the past 20 years or so.


John Welty
 

If you're asking me:


From: extremeprogramming@groups.io <extremeprogramming@groups.io> On Behalf Of Slava Imeshev via Groups.Io
Sent: Tuesday, December 3, 2019 12:43 PM
To: extremeprogramming@groups.io
Subject: Re: [extremeprogramming] What has changed for you over the past 20 years?

 

 

George, thank you for raising the discussion to the top level..... 


J. B. Rainsberger
 

How are things progressing for you working with someone else? What has changed in the past six weeks or so? 


On Sun., Jan. 5, 2020, 06:35 John Welty, <john@...> wrote:
I learned about Unit Testing when I wanted to learn about refactoring. I bought the Refactoring book and realized quite quickly I had something else to learn first. 
 
When I learned how to write software to test my software, I learned that I had a lot of working software that I no longer understood and could no longer easily gain an understanding of. I found long standing bugs that weren’t surfacing in operation but which must be causing hiccups at times. 
 
So my goal with TDD (new) and Test to verify a bug (for existing untested code) is to gain understanding and to clarify that gained understanding with well written tests. I can’t imagine investing software developer salaries in busywork (make the coverage tool show green). 
 
If it’s not advancing my understanding and capturing that understanding for my future self and others, it must be adding confusion to the code base and eroding developer confidence in making changes. Am I missing something?  
 
I’m still working on learning to think smaller when starting to approach a problem. I’m fortunate that most of my software is well contained; I don’t have other developers using it. I’ve been unfortunate that I’ve always worked alone and have only my own understanding of what authors mean when I read their books. 
 
I started making an investment in my own technical development late in 2018 by moving on from just reading books. I started buying some video courses that provided access to the author and stumbled upon the world of technical coaching. 
 
Starting on Monday I’ll no longer be coding solo. I have a new hire starting and I’m looking forward to put pairing and collaboration into practice. I’m quite eager to participate in any learning opportunities being facilitated by those who have substance. I’ve wasted way too much time learning from those who took it upon themselves to teach something they barely understand themselves. 
 


John Welty
 

It's been going great. Neither of us have worked collaboratively before so we're learning the ropes together. 

We took advice to minimize the tooling we use and to work as if we're remote even though we work together. As it turned out, I have been tied up in a lot of meetings and a road trip so in fact we are collaborating remotely quite a bit. 

We've now had over a half dozen pairing sessions which have proven to be beneficial to us both. We have been primarily using a ping pong style of pairing. 

I've encouraged him to spend some of each day going through your Worlds Best Intro to TDD which is also helpful as he is new to TDD.