BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Revisiting XP: be a thoughtful programmer by exercising more collective ownership

Revisiting XP: be a thoughtful programmer by exercising more collective ownership

I get astonished the more that I find how software engineers are passionate about struggling. Really, I sense a consistent appreciation for masochism throughout our beloved software development community nowadays. It shouldn’t have to be this way.

Why is that? Before I start, think for a moment about what you have just read. Do you regularly struggle at your work? Have you ever considered that you could be causing other developers to struggle as well? Do you feel frustrated about that unfortunate piece of code that you have just slightly modified, which ended up breaking the whole system because it was badly written?

Let's take a pair programming session. When a single challenge causes two developers to confront each other's opinions and knowledge, their notions of development might get questioned by their actions. While the ideal solution should be harmoniously reached collaboratively, it is also possible that just one developer’s view will be favored as he is the one which brings up the most prominent solution.

Such awkwardness will more than likely cause some disappointment, and if one also shows an ill-tempered attitude, there might also be some disagreement around the code ownership. In other words, if both developers don't peacefully wrap the challenge up together, the "winner" might claim the solution as his or hers own and give no credit to the "loser".

This is where developers can get frustrated with themselves and other developers, and that is because they hardly put themselves in other developers' shoes. The core of all this frustration stems from the developer’s personality.

Developer's personality

We are all artful individuals, and every single developer has his or hers own tenets when coding. For example:

  1. The logical reasoning when tackling a challenge

  2. The systematic steps when building a solution

  3. The preferences for code elegance, legibility, and formatting (for instance, how many spaces are there per indentation level?)

  4. The dubious boundary between the "less ideal solution" and "technical debt" (trust me, everyone has got one!)

If you still think that a team of human beings can fully agree on all those terms, think again. That is simply out of reach. A developer will not easily give up said tenets… they are part of his or hers developer's personality!

This means that other developers can identify you by figuring out your developer tenets, just by reading your code and making assumptions about you. In this way, a developer's personality is very unique, like a fingerprint.

This process of learning someone else's developer personality comes very naturally during code reviews. Mixed feelings arise, where one can agree with some ideas and disagree with others. A code review provokes a unidirectional confrontation between two developers’ personalities, just as pair programing does for a bidirectional confrontation.

Confrontation

A confrontation between two developers’ personalities can have different outcomes. While it can be extremely educational and uplifting, it can also be disturbing and troublesome if a positive attitude is not present, just like the aforementioned example.

Perhaps this is one possible explanation for the discomfort that pretty much every developer feels on his or her first pair programming experience. By participating in it, each party will be ultimately forced into a confrontation which could be avoided otherwise. Hence, each developer is taken out of his comfort zone and his or hers tenets will be challenged.

By no means is confrontation as bad as it sounds. But it still torments us all! As a matter of fact, we are not correctly exercising one of the most simple (yet often misunderstood) concepts of Extreme Programming: Collective Ownership.

Ownership

Think about how much open-sourced software you know. Pretty much all of it has dozens of books written about it, sometimes written by the same authors of the software, and rarely those books are open-sourced too. This happens because, in terms of ownership, writing code doesn't work like writing text.

It is much more natural to take part in collective coding than in collective writing. In other words, you can easily work with dozens of developers on the same 100 lines of code, but you will hardly work with dozen of writers on the same 100 lines of text.

Code ownership can also get tricky. Let's consider a controversial code ownership scenario which has happened to me recently:

  1. You work with a large codebase which is being developed by a geographically diverse group of many developers who do not know each other.

  2. All of a sudden you run into some existing code which you might need to modify for your current task. This code works, but you dislike the code structure, it is definitely not elegant, and you are dying to exercise all those cool trendy ideas you have been reading about (like functional programming). So you rewrite it. After your change, the code looks so good that you revel in how elegant it is!

  3. You finish your task and go take care of other stuff. A couple months later you have to revisit that very code again for a new task, only to find out that someone messed with your elegant code, so much so that it doesn't look elegant anymore… And this profoundly bothers you. Such elegance (which kind of belonged to you) was something you were proud of, and it is all gone now!

  4. However, rewriting that piece of code from the past is not really part of your scope for this new task, and there is a very high risk of touching something that has been delivered to production already, especially because there will be no QA round without a valid story on the backlog.

  5. You carry on with your current task, but every time you open that file your eyes gaze over this demoralized piece of code, again and again… So much so that you end up secretly tampering with it, only to provide a valid reason for you to receive a green light to put your clean hands into that dirty code and fix it once again.

  6. Congratulations, you took ownership of a company-wide code! Everyone will keep changing it for different reasons, and you will develop a deep appreciation for always revisiting the code, only to suffer again. You will start doing weekly reviews on this code and will spend way too much time fixing alignment issues, renaming methods to be more consistent, and rewriting comments in better wording. After so many changes, you will end up writing your name as the author of the code.

By no means am I saying that we should live with technical debts. However, technical debts must be tackled within a sustainable process instead of throwing everything a Hail Mary pass in fear that the code will remain as bad as it is. Think about it as any ordinary issue cycle: discovery, naming, planning, and also properly unit testing before refactoring. And all this is a team effort, to be fully accounted for!

Collective Ownership

Although not as hot as before, but still not outdated, Extreme Programming has tons of valuable teachings. One of its rules is Collective Ownership, which stands by the concept of synergy, i.e., collective work does more than the sum of its parts.

A very dangerous misconception here is that while collective ownership encourages each developer to feel responsible for the quality of the whole, one can easily feel that in reality no one is actually responsible for quality, which makes them feel alone in advocating for better code quality. Of course, it will be extremely hard if he or she tries to do it alone.

The way it should be viewed is: when the ownership is collective, one doesn't have to advocate code quality as if it were only his or her concern. Code quality issues should be fixed in a team-wide effort. Simply think it of a baseball team - we win together, we lose together.

A direct consequence is that no one person should ever become a bottleneck for changes. Such a bottleneck would happen when the knowledge behind the code is not properly shared, and then the code evolution starts to depend on a specific person. On the other hand, developing code while being considerate of the collective is not only enlightening, but you are indeed adding more reliability to the code, which will greatly cut the odds for further code quality issues. That is what I call doing thoughtful programming.

Here are a few more suggestions on being a more thoughtful programmer:

  1. Always strive to create unit tests as the code is being developed. Shoot for TDD whenever it is possible. This is a great way to self-document your code on the developer's perspective.

  2. Make sure you update the unit tests whenever you have to change any existing code. This will both cover your code, and share the knowledge about your new changes. If the original code author reads your new change and there is no unit testing, he might be inclined to question its alignment with the original purpose of the code.

  3. If you have to introduce a bunch of extra code in the middle of an existing method, just create a new method for your extra code and call it out from the original code. This way, the original method won't deviate from the purpose it was originally designed for, and its unit tests will still make sense, as the original code can be isolated from your new method through stubbing.

  4. Whenever writing more complex code, find some time to document your designs and related architectural consequences on collaborative tools like Wiki. Such documents usually get stale quickly, and that is because developers fail to update them quite as often as they should, so it is imperative to update the documentation as soon as possible after a relevant change.

  5. If you are writing some utility code, provide usage examples. A powerful approach is to write unit tests that will consume the utility code with real-life samples, instead of writing dummy ones. For instance, if you are writing a calculator, unit test it by doing more complex math related to your business logic, instead of testing that 2+2=4.

  6. Follow the code standards established by your team. If you think you can do better code than the current standard, stop for a moment to discuss with your tech leads in order to improve the current standards and have them adopted teamwide, instead of silently using different standards because they would suit you better.

  7. Although it might be seductive, don't let your code stand out too much. Code that stands out from the rest is not necessarily better, because it may end up introducing inconsistencies and possible issues, as you can't guarantee the rest of the team will understand your "new standard" (and you might be viewed as a show-off).

  8. It is always good to engage with the collective. Be self-motivated, discuss your approach, ask for feedback, and accept contributions from other people. Also, make sure to help people out, because many times that is when some of the best learning takes place. Don't ever think of it as a waste of your time. The more, the merrier.

The collective ownership mindset will become more natural the more that you practice it. It is a very valuable concept to have in mind during code review and pair programming sessions, in order to prevent frustrations by clearly understanding both you and your peer's place throughout the collective code.

I want to give special thanks to Sydney Burns for her thoughtful and artful editing contribution  for this article.

About the Author

Tiago Romero Garcia is a front-end architect in San Francisco, conference speaker and article writer, believer in servant leadership and ahimsa, focusing on equanimity through mindfulness. He can be reached by Twitter at @themindfuldev and his talks, articles and projects are available on his website.

Rate this Article

Adoption
Style

BT