Over a million developers have joined DZone.

Tragedy of the Common Library

DZone's Guide to

Tragedy of the Common Library

· DevOps Zone ·
Free Resource

Can you release faster without sacrificing quality? See how with our free ebook Strategies for a Successful Test Automation Project and a free trial of Ranorex Studio today!

Good intentions can go awry quickly in the world of software development. Imagine this common scenario: there are multiple teams building related projects at the same company. At some point, someone realizes that these teams tend to generate a lot of duplicate code; why not just create a common library that all the teams can reuse? Everyone agrees it's a brilliant plan, and so code begins to shift from each team's codebase into the common library.

Fast forward to two years later. Now everybody is using the common library to solve a lot of hard problems. That's good! At the same time, people would rather have a tickle fight with a komodo dragon than actually wade into the common code and make a significant change to the existing logic (author's note: tickle fight with a komodo dragon is not a euphemism). Why is everyone so afraid of the common code? Since a bunch of different teams have touched the common code, it's a giant mishmash of conflicting coding standards and duplicate abstractions. Even worse, all products now depend on it. The common library has become a Jenga tower, growing taller and more wobbly with each change. Everyone is now afraid to make sweeping changes in there, lest they send the tower tumbling down.

How did the common code get into this state? Well, it's because we're humans and that's we do: make a mess of our common places.

This problem is well known in certain circles as the tragedy of the commons. Wikipedia describes the problem as "the depletion of a shared resource by individuals, acting independently and rationally according to each one's self-interest, despite their understanding that depleting the common resource is contrary to the group's long-term best interests." This theory has been applied to problems like population growth, pollution, traffic jams, and now, janked-up codebases.

So, if this is a common problem because we humans are a bunch of dumb dumbs, what's the solution here? Well, this guy Ronald Coase proposed a solution that won him the Nobel Prize in Economics, and it's actually relevant to our problem. Coase theorized that, if property rights are well defined and negotiation costs are low, then just by assigning property rights, the interested parties will negotiate their way to a solution to the negative side effects.

How would you apply that fancy book learnin' to the common library? Well, you'd start by splitting the common library up into smaller packages, with an established owner for each package. Then, you make it easy for the teams to communicate and negotiate changes to these newly split-up packages.

Let's say that Team A owns the common Logging package and Team B suddenly wants a new feature in that library. In the olden days, Team B would've just hacked this up. Since it's not their codebase, they'd move fast to get this in, leaving few comments and no tests. After all, that's what everybody does in the common library and they know there's no one to call them out on it.

That won't happen here, though, since Team A is now married to this codebase. Team A could propose something like, "You guys do the work, then we do the code review and we'll own this long term." Team B could then make a counter-offer, like "How about you make the change, and in exchange, we'll implement your Feature Request X in the service client library that we own?"

As it turns out, ownership and fast, easy communication solve lots of software problems. Let's do more of these things!

As it turns out, a few other people have written on this topic before me. Good thinking, folks!

Get your test automation project off to the right start. Download your free test planning template and a 30-day no-obligation trial of Ranorex Studio today!


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}