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.<p>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 <i>must</i> be handwavy, because we haven't talked about specifics yet), then each practice comes pre-justified because it's part of the bundle.<p>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 <i>specific</i> practices that you'd like to see implemented, and then explain and show why you believe those <i>specific</i> practices will work.<p>"We should do XP" breaks down into "we should do TDD" and "we should do pair programming", but <i>it also breaks down much further than that</i>. 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, 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.<p>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 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.<p>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…<p>I feel like it all just comes down to:<p>- above all, be consistent but not too rigid<p>- talk with your colleagues, keep up to date with each other<p>- think about your constraints and goals frequently and check in with how you are relating to them<p>- work hard but not too hard<p>- 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!<p>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…<p>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.<p>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.
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.<p>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.<p>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.<p>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.<p>I <i>love</i> 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.<p>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.<p>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.
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.<p>And this effect on the diversity of your team is one I see a lot of XP advocates fail to address.<p>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.<p>Any workplace culture where this was forced upon me is something I'd leave immediately.
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!<p>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.<p>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.
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.<p>However, the question you need to ask yourself is whether if you believe that it is worth investing <i>all</i> your time on <i>every.</i> <i>single.</i> <i>ticket</i> 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.<p>How are you going to get that time back? (Remember, you will not get any of it back).<p>Do you really think it is worth missing weekends for this if you are behind on a deadline?<p>Are you really sure?