Overcoming Resistance to Extreme Programming
benjiweber.co.uk
benjiweber.co.uk
These kinds of bundle-of-practices-given-a-label feel very consultant-y to most developers, which triggers a ton of natural suspicion. Rather than looking at each practice on its own and showing how it fits into existing workflows, the bundle-of-practices is justified with somewhat handwavy explanations (and they must be handwavy, because we haven't talked about specifics yet), then each practice comes pre-justified because it's part of the bundle.
If you want to effect change in a good engineering org composed of rightly-cautious engineers, you can't give them marketing copy for a bundle-of-practices and expect buy in. Instead, you should use the bundle as a starting point for investigating the specific practices that you'd like to see implemented, and then explain and show why you believe those specific practices will work.
"We should do XP" breaks down into "we should do TDD" and "we should do pair programming", but it also breaks down much further than that. Start with "when I write a failing test before implementing a feature I find that I move much faster". Discuss specifics, not consultant-fueled buzzwords.
Turns out they wanted me to spend 8 hours a day pairing with clients. XP was their excuse to make sure that all your working time is spent writing code in front of a video feed - no downtime/thinking/checking emails. A micromanagement hell.
They also sent me straight to clients whose language and tech I had never touched, selling me (unknown to me at the time) as someone with a decade of experience in the language. When I discovered that and protested they told me the problem was my inhability to hide my lack of expertise from the client and handed me a digital copy of "how to make friends and influence people".
Let's just say, I'm very wary of programming gurus now.
As an engineer I like to insist on the right to decide which approach is the best for any given project. I am not saying there isn't a ton of good lessons learned in the foundation of those practises (there is). But for every project one has to talk about how to organize it best and that depends on a ton of things only some of which are technical.
TDD sounds great in theory, but in practice most of the time the requests from PMs are incomplete. They may have the happy path mostly figured out, but they have usually given zero thought to corner cases, error conditions, or second order effects. You can't write meaningful tests for these (the most valuable cases to test!) until you go a few rounds of iteration with the PM. And generally you can't explain it to the PM without at least a mockup of the situation. It's often faster to create a barebones implementation to demo than it is to create visual mockups that convey the complexity. And then you've written your implementation before the test anyway.
LLMs are very good at programming chores, albeit with supervision and verification.
But the role of your human pair is to do more than that. I am not keen on pair programming as it in the extreme (reductio ad absurdum ) it is a waste.
But I am denied human conversation in my day job, and it is very bad for my productivity. It is not the programming chores I need help with, it is help avoiding "cul-de-sacs". An LLM is hopeless at that It has no idea of the bigger picture, the passing of time, it feels no frustration and has no hope.
No, AI is not going to replace pair programming.
Walking through mockups and saying "ok, but what happens if I do this" is essentialy the same question as "what are the acceptance tests for this?"
Often that happens in various kinds of meetings over the course of feature development, when it would be more effective to just immediately create the tests up front, which can then go and be developed against. With current tooling, it's actually possible to get the PMs to participate in detail in writing tests. Although that point is often where I have gotten the most pushback.
Whether there is a self-conscious attempt to avoid being accused of dogmatics, or alternatively a fully embraced biblical dogma, it all feels like the same basic advice repackaged in new language. Sometimes the formalism is meant to create a framework to help the team organize better, but…
I feel like it all just comes down to:
- above all, be consistent but not too rigid
- talk with your colleagues, keep up to date with each other
- think about your constraints and goals frequently and check in with how you are relating to them
- work hard but not too hard
- have some systems, any systems in place, to check for poor work product and highlight good work product. What is good work product? Well, to use the famous quote, you’ll know it when you see it!
To be fair, some frameworks may obviously help some teams more than others, but like any tool evaluation and selection process, it always seems so highly contingent which process management method might work well or not, many might work equally well, and most of it comes down to the team and people more than it does the system…
I could be totally wrong as I don’t have much experience in teams or orgs beyond 5-10 people, but still… just my surface level understanding of all this.
I’m curious what others on here with far more experience and exposure to a variety of organizational frameworks have found and think about my assessment.
All of the attempts to pitch brand-name development practices also feel the same to me. It's always the same bullet points:
- This new process is going to be amazing and incredible and change your life!
- We're not going to force it, wink wink, but also here's a guide to downplaying your team's objections so you can force it upon them
- If anyone doesn't like it, it can't be because it didn't work for them. The only explanation is that they were doing it wrong and/or rejected it for invalid reasons.
- Vague acknowledgment that it's kind of painful and exhausting for the developers, but a promise that it's worth it [for the manager]
I think the most important consideration is to match development practices to the team and to accept that people have different preferences. This author’s preference is clearly for XP practices, but I see little acknowledgement that it’s a personal preference amid the bolded declarations that it’s incredible. The entire article is about convincing people to give it a try with little acknowledgement that maybe the team is right to reject it for their style and working preferences.
I’ve had several managers try to impose forced pairing over the years. Every time, a couple people really like it but everyone else is put on a path to burnout and leaving the company.
XP style practices (pairing, TDD, commit frequency) are also not a good match for certain types of development. If you’re pushing small pieces of a CRUD app and website around then having everyone commit frequently and work “at the speed of conversation” can make sense. If the team is doing complex work that requires deep trains of thought and intense focus over several days then forcing XP principles arbitrarily will not have good results. I last encountered this when a company reassigned a full-stack web dev manager to oversee some developers doing complex low-level work that spanned multiple systems. You could feel the seething rage as the manager demanded that everyone should be checking in releasable code multiple times a day and doing the TDD dance. His entire career was doing simple web apps and he couldn’t understand why we couldn’t just kick out incrementally complete commits every few hours for our complex systems work. Again, it set people up for burnout and quitting.
I love coding, but I'd rather work a McDonalds fryolator than pair for more than an hour at a time. Short bursts--fine. Mentorship--fine. That's not a joke or derision--I'm serious. Past an hour, the fryolater would be preferable.
In general pairing ties up and impairs the part of my brain that does design work, troubleshooting, and problem solving by splitting my focus. The social obligations that come from interacting with another human, like paying attention to what they are doing and saying, and their mental and emotional state, eye contact, my own appearance and affect--all of those distractions are costly. Not to mention pairing destroys the fun part--flow.
Fast forward a couple years and I land in a full remote team as a tech lead/manager role. I try to bring XP into the team, and the pain was real. Not a single person would get behind it. Needless to say, the culture of the entire org plays a huge role in the success of XP.
Never experienced it since... Each following employer has abused scrum to a/ say in front of stakeholders that scrum is in use and b/ utterly fail to use purely time-based estimations for tasks as a metric to a team's or a team member's performance. All this coupled with inept PM.
For us, the way it fell apart was the interface to upper management. Upper management didn't want to hear about story points and picking the most compelling features for a release. They wanted to see normal development plans and progress reports. They felt like we couldn't be under control if we were developing in an XP way.
It's not that we failed to deliver. It's not that we were behind schedule. It's that upper management wasn't comfortable.
By the way, one of the things we did was to hack our own process. (If you're trying to be agile by a rigidly defined process, you're not agile.) So a couple of the leaders would talk for a bit, and then they would say, "For the next two sprints, we're going to try changing the process in X way. After two sprints, we'll reevaluate." Drive toward a process that fits your team.
And this effect on the diversity of your team is one I see a lot of XP advocates fail to address.
I don't mind a team adopting it for those who want to do it. I do mind a workplace that is actively hostile to people for whom it doesn't work.
Any workplace culture where this was forced upon me is something I'd leave immediately.
I have held courses that involved me speaking in front of crowds and showing how things are done both in front of crowds and one on one. I have no problems with that, but pairing does not work for me.
If I wanted to socialize, talk constantly with employees, and set little bureaucratic hurdles for myself, I would have chosen to be a manager like the author.
My other concern would be disagreements. I have found even with code review that sometimes 2 developers fundamentally disagree on a point, and it’s painful to resolve. It seems like that sort of thing would happen even more frequently with parallel collaboration like this.
However, the question you need to ask yourself is whether if you believe that it is worth investing all your time on every. single. ticket every day and pairing for meetings and stand-ups every. single. day. for that salary you negotiated (or worse that you took a lower salary for) all for the chance to increase it +10% to show that you are "performing" well for the employee of the month award at the company.
How are you going to get that time back? (Remember, you will not get any of it back).
Do you really think it is worth missing weekends for this if you are behind on a deadline?
Are you really sure?