|
I've agreed to give a talk to a class of CS Majors, all college juniors, divided into two 50-minute segments with a short break between.
My inclination is to do what I've done in the past for working engineers, briefly describe XP and its core practices and then use a rough Planning Game to ask which two or three practices they'd like to learn more about. I'll try to steer them toward TDD, since that's the one I've gotten the most mileage from, but it'll be up to them.
I'll crib the list of practices from Ron Jeffries' site:
Any thoughts? I'm calling myself retired, so I have only an approximate idea of the state of the art in Software?Engineering. My impression is that some XP practices are now mainstream, others not so much.
|
You know TDD works.? I'd steer them to TDD.?
Cheers
I've agreed to give a talk to a class of CS Majors, all college juniors, divided into two 50-minute segments with a short break between.
My inclination is to do what I've done in the past for working engineers, briefly describe XP and its core practices and then use a rough Planning Game to ask which two or three practices they'd like to learn more about. I'll try to steer them toward TDD, since that's the one I've gotten the most mileage from, but it'll be up to them.
I'll crib the list of practices from Ron Jeffries' site:
Any thoughts? I'm calling myself retired, so I have only an approximate idea of the state of the art in Software?Engineering. My impression is that some XP practices are now mainstream, others not so much.
|
Hi Adam,
It might help to talk a bit about historical context (waterfall, lots of work-in-progress, massive failed projects of that era). Agile/XP/Lean were?initially reactions to conditions of the time -- conditions that will predate the memory of those you'll be presenting to. But some of those conditions appear to be making a comeback. I'm seeing a new cohort of product?managers, with the best of intentions, re-inventing waterfall as an obvious good. In talking about XP, you may be arming people with tools for their struggles ahead.
Dave
On Sun, Aug 13, 2023 at 4:04?PM Adam Wildavsky < adam@...> wrote: I've agreed to give a talk to a class of CS Majors, all college juniors, divided into two 50-minute segments with a short break between.
My inclination is to do what I've done in the past for working engineers, briefly describe XP and its core practices and then use a rough Planning Game to ask which two or three practices they'd like to learn more about. I'll try to steer them toward TDD, since that's the one I've gotten the most mileage from, but it'll be up to them.
I'll crib the list of practices from Ron Jeffries' site:
Any thoughts? I'm calling myself retired, so I have only an approximate idea of the state of the art in Software?Engineering. My impression is that some XP practices are now mainstream, others not so much.
|
Hi Adam,
A few things I'd stress in your situation...
* XP? was the first methodology to look closely at the day to day, even minute to minute details of what someone does to write a working program.
* XP defines a set of practices, the reasons for those practices and the interaction among those practices... i.e. how they support one another. This is often missed in a quick summary of what the practices are.
* You can use just some practices out of XP but for best results, understand the contribution of all the practices and define your own work process so you provide equivalent support. It's harder to do partial XP successfully than it seems at first glance.
As an example of the last point... if you are NOT doing pairing (or mobbing) what will you do to make up for the gap left by its absence?
Charlie
Hi Adam,
It might help to talk a bit about historical context (waterfall, lots of work-in-progress, massive failed projects of that era). Agile/XP/Lean were?initially reactions to conditions of the time -- conditions that will predate the memory of those you'll be presenting to. But some of those conditions appear to be making a comeback. I'm seeing a new cohort of product?managers, with the best of intentions, re-inventing waterfall as an obvious good. In talking about XP, you may be arming people with tools for their struggles ahead.
Dave
On Sun, Aug 13, 2023 at 4:04?PM Adam Wildavsky < adam@...> wrote: I've agreed to give a talk to a class of CS Majors, all college juniors, divided into two 50-minute segments with a short break between.
My inclination is to do what I've done in the past for working engineers, briefly describe XP and its core practices and then use a rough Planning Game to ask which two or three practices they'd like to learn more about. I'll try to steer them toward TDD, since that's the one I've gotten the most mileage from, but it'll be up to them.
I'll crib the list of practices from Ron Jeffries' site:
Any thoughts? I'm calling myself retired, so I have only an approximate idea of the state of the art in Software?Engineering. My impression is that some XP practices are now mainstream, others not so much.
|
Hi Adam,?
+1 on presenting first the motivation why XP was invented; the CS students' first thought is likely to be "why should I be interested?"? If you present this as the (work-)life-changing it was at least for me, you're likely to hook them.??
And the second thought of the students might be "is this stuff obsolete?"? I would then think at what's the alternative?? I myself don't have much of an answer, I feel like when you do less of XP, you don't have a credible alternative way of doing things.? Less of XP to me means more of "whatever", but I'd love to hear alternative views
Hi Adam,
A few things I'd stress in your situation...
* XP? was the first methodology to look closely at the day to day, even minute to minute details of what someone does to write a working program.
* XP defines a set of practices, the reasons for those practices and the interaction among those practices... i.e. how they support one another. This is often missed in a quick summary of what the practices are.
* You can use just some practices out of XP but for best results, understand the contribution of all the practices and define your own work process so you provide equivalent support. It's harder to do partial XP successfully than it seems at first glance.
As an example of the last point... if you are NOT doing pairing (or mobbing) what will you do to make up for the gap left by its absence?
Charlie
Hi Adam,
It might help to talk a bit about historical context (waterfall, lots of work-in-progress, massive failed projects of that era). Agile/XP/Lean were?initially reactions to conditions of the time -- conditions that will predate the memory of those you'll be presenting to. But some of those conditions appear to be making a comeback. I'm seeing a new cohort of product?managers, with the best of intentions, re-inventing waterfall as an obvious good. In talking about XP, you may be arming people with tools for their struggles ahead.
Dave
On Sun, Aug 13, 2023 at 4:04?PM Adam Wildavsky < adam@...> wrote: I've agreed to give a talk to a class of CS Majors, all college juniors, divided into two 50-minute segments with a short break between.
My inclination is to do what I've done in the past for working engineers, briefly describe XP and its core practices and then use a rough Planning Game to ask which two or three practices they'd like to learn more about. I'll try to steer them toward TDD, since that's the one I've gotten the most mileage from, but it'll be up to them.
I'll crib the list of practices from Ron Jeffries' site:
Any thoughts? I'm calling myself retired, so I have only an approximate idea of the state of the art in Software?Engineering. My impression is that some XP practices are now mainstream, others not so much.
|
It's really exciting to hear CS majors getting access to this information. I would try to emphasise a few key points. 1. XP was "extreme" in the early 2000s, but today many of the practices are "table stakes". (e.g CI/CD ) Some are still extreme?but proven to work via DORA research, (Accelerate book) like TBD, pairing, TDD etc. 2. These practices are "extreme" in the industry and uncommon because they are harder to adopt when you are an experienced developer, but when you learn TDD in college it's much much easier. It's a different way of thinking and so harder to adopt later in life.? Better to practice now to get the most benefits of it and rise above the competition when you leave school. brought to you by the letters A, V, and I
and the number 47
On Mon, Aug 14, 2023 at 2:04?AM Adam Wildavsky < adam@...> wrote: I've agreed to give a talk to a class of CS Majors, all college juniors, divided into two 50-minute segments with a short break between.
My inclination is to do what I've done in the past for working engineers, briefly describe XP and its core practices and then use a rough Planning Game to ask which two or three practices they'd like to learn more about. I'll try to steer them toward TDD, since that's the one I've gotten the most mileage from, but it'll be up to them.
I'll crib the list of practices from Ron Jeffries' site:
Any thoughts? I'm calling myself retired, so I have only an approximate idea of the state of the art in Software?Engineering. My impression is that some XP practices are now mainstream, others not so much.
|
I’ve been teaching two classes on agile software development to CS majors for quite a few years.
?
Start by asking how many have had summer internships, how many have been at companies that say they are doing agile, and what did that mean.? You’d be surprised at how much exposure to some agile practices a fair percentage of juniors and
seniors will have had, though often in name only, and rarely with any explanation of why.
?
I used to focus on individual practices such as testing and refactoring, but my teaching has evolved to address bad team practices. CS majors almost always focus on one thing: writing code as fast as possible. That leads to some major bad
ideas about how to work as a team:
?
- Working solo
- Working on many things at once
- Everyone working just on what they know best.
- Assigning everyone specific coding tasks up front
?
Rather than lecture them on why those are bad ideas, I have them figure it out for themselves. First, I have them make a list of important metrics. They usually get the first two but I need to guide them to the rest:
?
- Time to finish
- Code quality (bugginess, maintainability)
- Code integration conflicts
- Team bonding
- Individual learning
?
Realizing that those later metrics matter is the first learning. Then I break them into small groups, pick a practice, e.g., working solo, and have them discuss how it affects each of those metrics.? ?Lo and behold, they start to see many
potential problems. That’s the second learning.
?
Then they’re ready to hear about agile practices to try instead, like pulling vs pushing tasks, swarming, TDD, etc.
?
Christopher Riesbeck
Associate Professor, Computer Science
Director, CS Master’s Program
Northwestern University
?
Home page:
?
|
Hi Chris,
Some context would be helpful.? What year in the curriculum were these?classes?? Were they prerequisites for other classes?? Were they optional classes?? If so, what percent of students in the major opted to take them?
Thanks,? Steve.
On Mon, Aug 14, 2023 at 8:06?AM Chris Riesbeck < c-riesbeck@...> wrote:
I’ve been teaching two classes on agile software development to CS majors for quite a few years.
?
Start by asking how many have had summer internships, how many have been at companies that say they are doing agile, and what did that mean.? You’d be surprised at how much exposure to some agile practices a fair percentage of juniors and
seniors will have had, though often in name only, and rarely with any explanation of why.
?
I used to focus on individual practices such as testing and refactoring, but my teaching has evolved to address bad team practices. CS majors almost always focus on one thing: writing code as fast as possible. That leads to some major bad
ideas about how to work as a team:
?
- Working solo
- Working on many things at once
- Everyone working just on what they know best.
- Assigning everyone specific coding tasks up front
?
Rather than lecture them on why those are bad ideas, I have them figure it out for themselves. First, I have them make a list of important metrics. They usually get the first two but I need to guide them to the rest:
?
- Time to finish
- Code quality (bugginess, maintainability)
- Code integration conflicts
- Team bonding
- Individual learning
?
Realizing that those later metrics matter is the first learning. Then I break them into small groups, pick a practice, e.g., working solo, and have them discuss how it affects each of those metrics.? ?Lo and behold, they start to see many
potential problems. That’s the second learning.
?
Then they’re ready to hear about agile practices to try instead, like pulling vs pushing tasks, swarming, TDD, etc.
?
Christopher Riesbeck
Associate Professor, Computer Science
Director, CS Master’s Program
Northwestern University
?
Home page:
?
|
toggle quoted message
Show quoted text
I’ve been teaching two classes on agile software development to CS majors for quite a few years.
?
Start by asking how many have had summer internships, how many have been at companies that say they are doing agile, and what did that mean.? You’d be surprised at how much exposure to some agile practices a fair percentage of juniors and
seniors will have had, though often in name only, and rarely with any explanation of why.
?
I used to focus on individual practices such as testing and refactoring, but my teaching has evolved to address bad team practices. CS majors almost always focus on one thing: writing code as fast as possible. That leads to some major bad
ideas about how to work as a team:
?
- Working solo
- Working on many things at once
- Everyone working just on what they know best.
- Assigning everyone specific coding tasks up front
?
Rather than lecture them on why those are bad ideas, I have them figure it out for themselves. First, I have them make a list of important metrics. They usually get the first two but I need to guide them to the rest:
?
- Time to finish
- Code quality (bugginess, maintainability)
- Code integration conflicts
- Team bonding
- Individual learning
?
Realizing that those later metrics matter is the first learning. Then I break them into small groups, pick a practice, e.g., working solo, and have them discuss how it affects each of those metrics.? ?Lo and behold, they start to see many
potential problems. That’s the second learning.
?
Then they’re ready to hear about agile practices to try instead, like pulling vs pushing tasks, swarming, TDD, etc.
?
Christopher Riesbeck
Associate Professor, Computer Science
Director, CS Master’s Program
Northwestern University
?
Home page:
?
|
That’s great to?hear, Chris. Great work!
On Mon, Aug 14, 2023 at 11:06 AM Chris Riesbeck < c-riesbeck@...> wrote:
I’ve been teaching two classes on agile software development to CS majors for quite a few years.
?
Start by asking how many have had summer internships, how many have been at companies that say they are doing agile, and what did that mean.? You’d be surprised at how much exposure to some agile practices a fair percentage of juniors and
seniors will have had, though often in name only, and rarely with any explanation of why.
?
I used to focus on individual practices such as testing and refactoring, but my teaching has evolved to address bad team practices. CS majors almost always focus on one thing: writing code as fast as possible. That leads to some major bad
ideas about how to work as a team:
?
- Working solo
- Working on many things at once
- Everyone working just on what they know best.
- Assigning everyone specific coding tasks up front
?
Rather than lecture them on why those are bad ideas, I have them figure it out for themselves. First, I have them make a list of important metrics. They usually get the first two but I need to guide them to the rest:
?
- Time to finish
- Code quality (bugginess, maintainability)
- Code integration conflicts
- Team bonding
- Individual learning
?
Realizing that those later metrics matter is the first learning. Then I break them into small groups, pick a practice, e.g., working solo, and have them discuss how it affects each of those metrics.? ?Lo and behold, they start to see many
potential problems. That’s the second learning.
?
Then they’re ready to hear about agile practices to try instead, like pulling vs pushing tasks, swarming, TDD, etc.
?
Christopher Riesbeck
Associate Professor, Computer Science
Director, CS Master’s Program
Northwestern University
?
Home page:
?
|
Primarily juniors, seniors, and MS students, with a sprinkling of sophomores. Most CS have worked on student teams even if they haven't internships. The large enrollments in almost all CS classes had led to a lot more team-based projects in all classes. This course assumed programming experience, and most have had some full-stack experience. Optional class but one of the more popular electives, since so few CS classes are about development rather than CS.
|
Thanks for the background.
I tried to introduce TDD in the first two programming courses where I taught with some success.? The biggest problem was that being a prerequisite for other classes had crammed the curriculum with so much specific content that there really was not room to do it, so some specific programming constructs were barely covered,?like case statements.? Another problem was some instructors of subsequent classes assuming waterfall in their classes, but nothing I could do about that.
Also, I believe that one of the driving forces for Agile is that requirements change in the real world.? Students HATE when the requirements change, so I would devise a series of programming assignments where each assignment built on the previous one but with a few changes as well as new requirements.? ?The students who did not get it would start from scratch each assignment.
On Tue, Aug 15, 2023 at 6:36?AM Chris Riesbeck < c-riesbeck@...> wrote: Primarily juniors, seniors, and MS students, with a sprinkling of sophomores. Most CS have worked on student teams even if they haven't internships. The large enrollments in almost all CS classes had led to a lot more team-based projects in all classes. This course assumed programming experience, and most have had some full-stack experience. Optional class but one of the more popular electives, since so few CS classes are about development rather than CS.
|
I wrote the first line of code, 4 years ago, of a project that now runs simple robots all around the world.
I also teach set theory to toddlers via the missus's child care center.
Sucks to be me to have 2 commuter-proof jobs!
On X (Twitter) as @RobRepMan?
|
Re testing: in my AI programming class, every exercise is driven by unit tests, but I don't get into the more important part where they have to learn how to define the tests themselves. Students get a little practice with that in my full-stack class, using Vitest for React applications, but it's just a taste and doesn't given them real practice with the test-code-refactor cycle. A colleague occasionally offers a 10-week class completely on testing with some very high expectations of reliability that force them to take testing seriously.?
Re requirements change: that's a big focus of my agile development class. Every team has their own client with a specific idea, but it's in a state where requirements change dramatically as working slices are delivered weekly and evaluated. "Embrace change" is the core theme, using backlogs and user stories rather than a useless upfront weekly plan of what will be built, so that items with most value first are built first. This is often done in conjunction with a professional masters class I run for product designers on how to be an agile client.?
|
Thanks for all the tips! My talk has been postponed due to scheduling conflicts. I'll post an after-action report once it takes place.
|
Re testing: in my AI programming class, every exercise is driven by unit tests, but I don't get into the more important part where they have to learn how to define the tests themselves. Students get a little practice with that in my full-stack class, using Vitest for React applications
Ya learn TDD in a less test-hostile?environment, such as pytest, before going for TDD in views
I TDD this:? The new grid looks funny because they used the device wrong
|
Chris,
On a side note, I did my AI programming in Prolog.? Wimped out on unit testing for 2 reasons:
1. Prolog code is kind of a test already.
2. I did not see how to do it anyway.
On Tue, Aug 15, 2023 at 6:36?AM Chris Riesbeck < c-riesbeck@...> wrote: Primarily juniors, seniors, and MS students, with a sprinkling of sophomores. Most CS have worked on student teams even if they haven't internships. The large enrollments in almost all CS classes had led to a lot more team-based projects in all classes. This course assumed programming experience, and most have had some full-stack experience. Optional class but one of the more popular electives, since so few CS classes are about development rather than CS.
|
The AI class code uses a Horn clause deductive retriever in Lisp which is tested with lisp-unit. My AI class in Lisp uses , a minimal unit tester I wrote that was open-sourced a while ago.
?
There is but I've not used it.
?
?
|
James Grenning
Chris Riesbeck