2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- September 20, 2017
- Collaborate
I’ve been writing a lot recently on pair programming and mob programming and I’ve been syndicating my posts at Dzone.com, which is a web portal for software developers. I’ve received some scathing comments about pairing and mobbing from people who’ve obviously never tried it. If something doesn’t work for you then by all means abandon it, but don’t talk with authority about something you have no experience actually doing. I have experience introducing hundreds of professional software developers to pair programming and when done well, I can tell you the people who were most skeptical—and there were several—often turned out to be my biggest supporters and the people who go on to organize pairing within their organizations.
There is a damn good reason for that. The reason is that it works—it’s helpful, it’s useful. Once we get over the stigma of actually doing what we do in front of someone else and realize that just like us the other person is fallible but has figured out things, different things than we have figured out, and that we can become a lot better by learning what they do—when we’ve figured these things out, we get excited about pairing.
If you value the code qualities we’ve talked about here, and work together with your team by just doing code reviews, you don’t even have to pair. Just talk to each other. If you just do that, you’ll see the knowledge and skill level of the team start going up rather quickly.
If you don’t pair then at least read each other’s code, and write code in such a way that it blends with the rest of the code in the system so that people reading the code can’t tell who wrote it. That’s what collective code ownership is all about.
The code in your system should embody the standards and practices of your team and that means everyone on the team. What good are standards and practices if not everyone follows them?
If most of the team can work on most of the code it makes for a healthier work environment. Critical team members don’t exist so people can take vacations when they need to. If someone gets sick, it doesn’t stop the whole team from working.
Pairing and collective code ownership are fundamental practices in Extreme Programming and help promote cross functional teams.
Previous Post: « Collective Code Ownership
Next Post: Name Things Well »