Pair Programming is not Optional

Pair Programming is one of the most simple and yet harder on XP practices. It's amazing how much sense of private ownership we built before embracing XP practices, lots of folks argue that private ownership is better or fits better for they believes. For years I had this thoughts about my classes are not yours.

Some mindsets are harder to get, like developer written tests, that's hard one too but I will not talk about tests today, this is another conversation :D Ownership has power and this is one of the compelling reasons what should you care about pair programming.

Here comes the fear


When you don't understand/share the values behind pair programming you maybe end up in this kind of fear driven situations. First because often you notice that you don't have trust in your team, so people start thinking that maybe someone could screw up they're code and you will get blamed.

People start thinking pair programming will generate more waste and re-work then never, management often thinks on waste too, because this *logically* make sense,have said that they start connecting the dots and feeling they will lost of the developer capacity in at least 50%.

Managerial feeling about loosing capacity is true but the really would be different. The believe is caused by the  root mindset of control and "building" software. Developers are always learning, Agile software development is about learning and doing it effectively. 

Right shift to Learning Mindset


My point here is not mention this old boring survey that everybody knows that 64% feature are not used, if they are not used they are waste. My point is mention that we end up in this kind of massive waste because we off don't listing up our real customer.  

XP practices are about establish real and continuous communication with the customer and the business. One practice is the on site consumer, this could not possible, because of the nature of the business now a days. Easier we get our selfs in situations that the business in one side of the world and the developers are in other corner, It's really better have business and developers in the same building or in the same room, today I get happy when I get they in the same timezone :D

Even in the distributed environments I do believe we can take advantage of the XP development culture, for instance, in order todo pair programming we actually don't need do it only with developers, sometimes and offen times to time you can do it with your product owners.

Is not the same pair programming that you do with other developer, BUT offen this really help to create a bridge between business and IT and let people figure out and discover things together. 

Business Rules and flows could be easy validated doing this developer business pair programming, and this feedback is really gold and it worth doing it.
Others times you can do pair programing with infra-structure guys or even folks who work with database or  outside of your team, all the points of view counts and help to create a caring culture, people must care about code, doing pair programming is caring about quality and code.

I do lots of pair programming using Skype, because I can see and talk with people and also share my desktop, so give us the tooling needed by such task.

Pair programming offen creates opportunities to have very valuable business conversations about what the software if or who should the software performs some tasks and behavior in other ways. When you do that coding the things get really cheap, so that thoughts about losing developer capacity change because this feedback you put you on the right track again.

BUT I shall not lie to you, I get really exhausted after the pair programming session, I  do think much more about the problem and care a lot more about what we are doing, if I'm not coding I get really critical about the code that I'm looking in front of me this could be nothing BUT good.

Other type of pair working related that helps a lot is doing tests or review the testes with the POs, this is another great opportunity to learn about business rules and make sure that we are coding what must be code it.


Pair programming leas to refactoring and more communication, because if you need touch other parts of the code that your are not familiar nor confident you should talk with your team mates or business folks in order to understand it and must change it if possible.

In the end of the day you will improve your design, have more tests and people always learn new development techniques and your are always helping to spread the business knowledge. How many times did you complain about having few people knowing about specific parts of your system ? Doing pair programming you let and share the business knowledge, this is good not only because of the technical excellent  improvements in the code but also because make it easy to people work here and there.

Collaborative ownership is what you need, if people care about others job they will not let crap be shipped by the end of the day. Not only the engineer quality will be improved but the team it self will be more united.

Cheers,
Diego Pacheco

Popular posts from this blog

Telemetry and Microservices part2

Installing and Running ntop 2 on Amazon Linux OS

Fun with Apache Kafka