This time I want to write of a big change that occurred in my way of working during this professional year.

The shift from a derived XProgramming methodology, including a strict pair programming centered way of writing code to a solo programming way.

In this post I want to tell you my experience with XP and the differences that I found with the new way of working.

The Truck Number

Project’s Truck Number = The number of devs that must be hit by a truck before some knowledge on the project is lost.

With constant pair programming (PP from now on) this number is never less than 2 and this includes missing the Expert Of That Thing™.

If a codebase has been fully developed in PP with pair rotation, every member of the team is able to quickly understand any part of it without reading any sort of documentation, the code is the documentation, because it’s the product of a collective mind.

In my experience in 3 different teams working on 3 different projects using different technologies and different “visions” on how to write good code, PP helped me a lot to reach full productivity in less than 2 months.

I mean being able to fully understand the business, the code visions, being able to join a tactical meeting and feel that my opinion matters.

Most of the documentation that we were producing consisted of a daily journal that every pair used to write at the end of the working day.

The journal contained the outcome of the day, new ideas, plans for the day after and problems.

Of course there were some specific docs about APIs, procedures and whatever but I can say that the journal was the most important one.

IMHO that fits the concept of “incremental documentation for an incremental development” because it’s literally day-to-day documentation! Take a look at this.

Shared Codebase and the Team

I don’t know if it’s common or not to every dev to work on a codebase shared between more than 4 people.

I’m currently working on a codebase that is shared between more or less 12 devs and the divisions between the teams and which codebase they touch is more than foggy, kind of shared/not shared I would say.

Is more than common when you find a piece of code that you are not suppose to touch and has not been wrote by someone in your team to just pass over it without caring, and the end is ‘ok’ to think that is not of your concern.

For peace’s sake maybe.

But

Pair programming showed me that when a code is bad you should not stay silent before it.

And you have to tell to the person who wrote it why it is.

That code is also yours, you are working on it and the results of your team depends also on that giant switch/case.

It means that the whole team must have the shared target of improve it in the best way as possible.

Studying and sharing knowledge is a way to find out which is.

Is not only about sharing code, is about sharing successes, failures, skills, commitment and trust.

Being part of the Team.

From Brat to Senior

One of the best parts in my opinion of PP was mentoring and also the one that put me in some impatient work situations ever.

When you have to work side by side with some fresh hired post-degree junior dev with overgeneralization and comments mania and you are the sheriff in town it’s always hard to keep your common pace slow.

Good part is that it’s just impossible to not learn something doing PP, maybe that something is not that much if you are the Senior in the pair but for sure for the other there’s no better way to grow as a developer than to be mentored in this way.

And there’s no better way to understand what are you doing as a Senior than explaining it to someone.

Simplicity

Pair Programming is tiring.

Because you have to deal all the time with another head, fighting sometimes, defend your opinion others.

And if code quality and the red-green-refactoring cycle have taught me something for sure it’s

Yo man! Keep it simple!

Huge artifacts with absurd combinations of configurations, flavors, colors are really not necessary for 90% of the situations.

And for the remaining 10% there’s an external module.

If I have to deal with my pair why should I lose time to implement the most complex solution, test it and fight for this idea?

Probably I just need to detach from the keyboard for some minutes.

Conclusion

These are the results of my experience with this way of doing software in a team.

I don’t think is the best way but if you are having any kind of problems in your team related to social dynamics or knowledge sharing this might be something useful to consider.