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

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all languages in p
Keep reading

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail
read more »