By Alex Bennett
Most people have never heard of Extreme Programming. It sounds like some sort of American Gladiator HackerRank that's probably unpleasant or at best exhausting. In reality, it's a comprehensive approach to the Software Development Lifecycle proposed in 1999 by Kent Beck and isn't terribly different from the original Agile Principles. Beck was actually one of the signatories to the Manifesto for Agile Software Development. Extreme Programming, or XP as it's referred to, simply, "...takes commonsense principles and practices to extreme levels. If code reviews are good, we'll review code all the time (pair programming)."
We've used Extreme Programming at Symbiont in our Mortgage business line for more than 18 months now. XP is not a plug-and-play approach that just works. Like any good tool, it can be used in a variety of ways and—if we've learned nothing else—knowing how to use it is key. This article will be the first in a series reviewing the role of XP in our team from different perspectives: business owner, engineer, and product manager. The goal is to provide a candid perspective on XP and how it works in practice for anyone thinking about giving it a try or wondering if it lives up to its hype. As the lead of our Mortgage business line, I will throw in two cents from a "management" perspective.
The hardest thing to justify about XP is pair programming. The typical argument is that it is inefficient for two engineers to work on one problem when they could be doing two. In our team, not only do we pair program, but we also "mob" program with 3 or more people, which seems even harder to rationalize. The XP rebuttal is that multiple minds generate code that is so much better, it actually results in fewer errors, refactoring, etc., and saves time in the long run. Our use of mobs is primarily for cross-functional teams to have multiple skillsets working on a single feature. In that way, we can have frontend and backend engineers working simultaneously to define API endpoints and schemas together, rather than trudging through integration later on.
Determining when XP is the right choice for a development team
For the sake of argument, I can look back on what our team has done and imagine developing the same features individually rather than in pairs or mobs. In that scenario, we would probably have accomplished more "work," have more functionality in place and be further along in our roadmap. But we would also have more blind spots. Whether we realized it or not, we would have less test coverage and less cohesiveness in our code base and design patterns. Even more importantly, the understanding of components would be distributed among fewer people and there would be natural "experts" who wrote particular parts of the system. Are those factors deal-breakers? Not necessarily. In a well-established domain, it may be redundant for pairs of engineers to work on solved problems where they simply agree with each other.
XP is a high-cost approach and the return you get from it depends on your use case. You are actively choosing to do things in a more time-consuming and challenging way. This comes to the crux of XP and why it’s a good fit for the Symbiont team. We use blockchain to capture the entire lifecycle of an asset in a decentralized network. Most of our work has never been done before so we have to innovate and iterate within the bounds of the nascent technology. Especially for a market with the size and complexity of mortgages, the extra brainpower on each line of code is critical to the strong end-product we’re proud to deliver.
Culture fit is also critical. You will need a team of engineers who are willing to spend 6+ hours a day conversing with their colleagues. There are extremely talented engineers who would never touch XP just by reputation alone. In the right contexts, the benefits of XP will outweigh their costs in the form of more stable teams, higher quality applications, and paradoxically faster deliveries.
How XP builds a stronger, more accountable team environment
One benefit of XP that surprised me is it has generated a sense of collective ownership in our product. Part of this comes from mobbing since no line of code is your own; even if you physically typed it, you were working with someone else who has just as much of a claim to it. The practice of quick iterations also seems to engender ownership. Rather than spending weeks or months on a single component, engineers can move around the application and contribute in a variety of places. You also know when you start a feature that it will be done in a matter of days and available for others to make use of or continue developing. At first, that seems like a liberating prospect but you quickly realize it actually puts a greater responsibility on you. Your teammates have a dependency on you to make sure you do the right things the right way or the whole process will quickly devolve. It replaces a git blame culture with personal responsibility which is highly aligned with the values we prize at Symbiont.
I don't mean to imply that XP is a voodoo remedy to make amazing software with enthusiastic teams. Compared to an off-the-shelf Agile approach everyone is familiar with, it requires more effort to communicate and alleviate friction points. Few people have meaningfully done XP before and there is a natural tendency to regress to standard behaviors like solo programming or long-lived branches. My main role as the business lead is to hold a mirror up to the process and call out behavior that is non-extreme programming. Not to correct or assign blame, but to ensure there is justification to bucking an approach we have collectively agreed to. Trusting your team members to make those decisions in good faith is just as important to XP as pair programming. Even though it is technically Agile, Extreme Programming repudiates the rituals of stand-ups and sprints which are business tools to monitor and manage engineers. In some sense, that may be the greatest value we get from XP: by deconstructing the "standard" development methodology it forces us to think a bit harder about how we develop and actively opt-in to the decision. It replaces trust in the process with trust in ourselves.
To be sure, this is only part of the picture. My take on XP is from an external perspective and is focused more on outcomes rather than the day-to-day experience. In future installments, my colleagues in engineering and product management will share their perspectives on our development methodology and how it contributes to their day-to-day work lives and the end product.