They missed perhaps the most important reason for resistance to introduction of Extreme Programming (and any other labeled bundle of practices): resistance to cargo culting.
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.
I worked for a famous UK consultancy that advocated for XP, lasted about a month.
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.
The biggest problem I have with these practises is that just following them would be counter to what good engineering is — basically like the old saying: "If all you got is a hammer..."
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.
I, personally, am very much going to push back against pair programming as a default. Being "on" all day, interacting with people is completely exhausting. Yes, I've tried it. I can do pairing for an hour or two, then I'm pretty much shot for any social interaction for the rest of the day. Including at home, which is a problem.
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.
I have found it (difficult, but) effective to actually make PMs sit with engineers and hash out the most important test cases for this reason. Especially under a deadline, it's easy for PMs and designers to sling mockups and stories at an engineering team, who then have to work out during development what all the behaviours implied by that documentation should be -- many of which aren't even edge cases, they just weren't well-considered.
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.
AI is going to completely replace pair programming for popular languages/frameworks, if it hasn't started already. Human + AI is going to be close to as good as 2 humans, perhaps better, and only one salary.
> Human + AI is going to be close to as good as 2 humans
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.
This is a form of pair programming I could get behind, but I will not abdicate my creative tooling to a 3rd party whose priorities are vastly out of alignment with mine own. When I can run a good, free software AI on my laptop or a reasonably priced external box then I'll be interested.
I can’t help but feel that every different flavor of formalization of the process of collaborative [software] development feels… nearly the same? At the end of the day.
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.
> I can’t help but feel that every different flavor of formalization of the process of collaborative [software] development feels… nearly the same? At the end of the day.
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]
The part about Extreme Programming not being for everyone and the recommendation to not force it are good, but they’re a small part of the article.
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.
Pair programming is draining for most introverts, and there are a lot of introvert programmers.
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.
I worked in a place where we took XP very seriously. The culture supported it. And I can say that place was one of the best places to work and learn in.
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.
I can also attest to having a similar experience with scrum. I've seen it thrive in a single company I worked with, coupled with sharp product managers that know their shit better than any of us developers but at the same time take feedback to heart.
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.
I too have worked at a place that took XP very seriously, and it worked very well.
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.
Pairing is the main issue to me, and the one I see most often. For a lot of neurodiverse developers it is not an option. I would leave any workplace that tries to force pairing, because I value my mental health enough to not force myself to endure something I know the mental cost of.
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.
My resistance to XP is mostly driven by me having 0 desire to pair program with any regularity. Maybe once in a blue moon for something very tactical. This was true when I first encountered it in the early aughts, and it's true now. No thanks.
Any workplace culture where this was forced upon me is something I'd leave immediately.
That's mostly what I meant by once in a blue moon tactical situation. Even then, I don't generally want someone hovering over my shoulder. And I don't love hovering over someone else's shoulder either. I'll usually turn it into a "lesson" more than a "pair session"
Teaching is very different from pairing. I will not pair. I'd rather quit than pair. It's anxiety-inducing to an unhealthy level for me. But I'll happily sit down and show someone how to do something. The two are different because in one instance the focus is on explaining rather than doing, and I will go through things I believe need to be explained, not build something from scratch.
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.
I like to think about something for a long time in my head, write it all out at once, and then work the bugs out with "print" statements, all by myself. If this makes me a monster, so be it. But I've worked hard to arrange my career so I can avoid all of the stuff this guy writes about. And I know there are more of you out there!
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.
I’m not sure about the idea of delivering what is requested and no more. It takes away the professionalism and ability to think up creative solutions to problems and adjusting.
I can see why this would be more productive and produce better code. But is it fun? A lot of the joy I get from working is in solo creation - building prototypes without a plan, playing with them, iterating, showing to the team. It seems like that sort of workflow is lost with extreme programming.
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.
Since there is zero evidence or reasoning for any of the claims being made, it's your preferences vs. mine. I'd prefer you get off my dick and let me work without worrying about fitting changes into completely arbitrary time scales and ways of working.
Your subjective feelings are not valid logical justification.
There is no problem with pairing or with going with extreme programming values. In fact I support the majority of the points in this article.
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?
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.
reply