Posted on byTeams, not individuals, build most software systems. The organization of these teams thus strongly impacts the software they build.This is old news.
For example, Conway’s law illustrates that the architectural decomposition of a system into components happens along communication structures 1. Naggapan’s study on bug data from Windows Vista shows that organizational structure is a significant predictor for fault proneness 2.These empirical results resonate with my own experience.
Often, the problems our static code analyses reveal in a code base are symptoms of underlying organizational problems. The larger the organizational problems, the bigger their impact on code quality.Unfortunately, on this level of abstraction, this insight is pretty useless, since it is too abstract to be operationalized in a project context. To make it applicable, I want to boil it down to a single aspect in this article: reuse.
From my experience, it is one of the code characteristics that reveals most about collaboration between teams. Posted on byWe have had countless discussions about code clones with the teams responsible for their maintenance. These teams generally accept that some of the clones in their software are the product of copy & paste. In many cases this is obvious, since the clones share some quirks that can only be plausibly explained by copy & paste (e.g. Identical typos in comments).One hypothesis that comes up time and again, however, is that some or many of the clones were not created by copy & paste, but instead were written independently and then evolved into the same form.
Convergent EvolutionThis hypothesis reminds me of convergent evolution, where environmental factors drive independent evolution of similar traits in species whose ancestors do not show those traits. For example, both pill bugs and pill millipede have evolved similar defenses, and consequently look similar, but belong to different branches of.