(2022-02-03) Jeffries ExtremeProgramming Thoughts

Ron Jeffries: Extreme (Programming) Thoughts. Chet Hendrickson said something to the effect that when we were first talking and writing about Extreme Programming, we said that it was simple enough that ordinary programmers could do it. He went on to say that on the C3 team that first did XP, the team was self-selected from a group that had been immersed in the domain, and in Smalltalk, for well over a year, and that had all been programming for quite a few years before that. He wondered whether we should have said that yes, you do have to be good to do XP.

I’m asking that the product grow in running tested ready-to-ship code (increment) from the very beginning, every day, until we finally stop funding the effort.
That [DELETED] ain’t easy!

We can’t just test manually. Since we are changing the program every week, we need to test pretty much everything every week.

First, we have to learn how to write code that is amenable to testing with automated tests. Second, we have to learn how to write automated tests. And third, we have to learn how to write tests that don’t require rewriting every time something changes.
That [DELETED] ain’t easy!

First, we have to be capable of creating good designs. Second, we need to be able to move from one good design to a better one smoothly, so that we can do it every week. Third, we have to do it without breaking anything.
That [DELETED] ain’t easy!

Some refactoring steps are quite simple and easy. But the transition from one design to another isn’t always simple and easy. Sometimes we just can’t see a series of simple steps to get from point A to point B. Sometimes, even if we can see them, there are so many steps that the code would remain broken for a long time. We don’t have a long time. We need to deliver another Increment, this week, if not tomorrow. Ideally tomorrow.
That [DELETED] ain’t easy!

Believe me, someone who has been doing this for a quarter of a century now, TDD micro-testing is hard. The learning is endless, the need to refocus on smaller is endless.
That [DELETED] ain’t easy!

each subgroup needs to integrate its work incredibly frequently (continuous integration, trunk-based development)

So we all want to check in essentially immediately after checking out

Ideally, we’ll do this:
Check out;
Tiny refactoring;
Tests still run;
Check in;
Repeat.

That [DELETED] ain’t easy!

There are other skills and practices that are part of Extreme Programming

Pair Programming: We need everyone to be able to work on everything, to the degree possible. We need to make very few mistakes.

Ensemble Programming: Also called “Mob Programming”, this is an approach where the whole team works together at one machine to build everything.

Whole Team: To move this quickly, we need the team to have all the skills necessary to build the increment. Not just coding and testing, but also the skill to decide what to do next.

if we’re to do this well, we need to increase people’s skills as rapidly as we can.

not built in to programmers off the street

Extreme Programming, and its relatives Scrum and SAFe, are very difficult to do well

Software development is hard. The best ways we currently know to do it, the so-called “Agile” approaches, are hard. The not-so-good ways, often clumped under “waterfall” are, frankly, harder. The not-so-good ways tend to lose the essential property of software development

Maybe we need to put the Extreme back into Extreme Programming. Maybe we need to put the Extreme back into all programming. Maybe we need to put the Extreme back into our lives.

This led me to ask: Is there a good example documented of taking mid-sized feature, showing how to keep splitting stories until they're tiny; spreading stories across multiple devs; clarifying interaction of trunk-based development, Acceptance Tests, and Feature Toggles and A/B Test Flags? Ideally web-dev, in RubyOnRails or Django/Flask. Maybe as v2 of the standard ToDoList app? Alas no answer.