--- title: 'Social Debt in Development Teams' subtitle: 'Community Smells Explained' date: 2021-05-27T07:45:00 categories: - programming tags: - software engineering - collaboration --- The first thing that must have sprung to mind while reading the title of this post was probably **Technical debt**. At least that was my first thought when I read about _social debt_ in an academic article called "[The Architect's Role in Community Shepherding](https://sci-hub.st/10.1109/ms.2016.144)". We as enterprise software developers are more than aware of technical debt when working with legacy code, and the many code smells that come with it. When in luck, some of them get fleshed out in the form of technical user stories when the product owner has had a good day and approves a few stories he or she thinks is irrelevant. Just to be clear, let us rehash a few definitions. What is technical debt? The cost that comes with doing things "the easy way" when a better technical approach should have been taken instead. If it is not fixed in time, it accumulates 'interest', meaning certain improvements will become harder over time. For instance, a few [Singleton design patterns](https://sourcemaking.com/design_patterns/singleton) that are abused but tolerated until it is too late to remove the keyword `static` without breaking a bunch of things. Abusing static variables is also a well-known [code smell](https://www.martinfowler.com/bliki/CodeSmell.html), a term coined by Kent Beck but really popularized by Martin Fowler's [Refactoring book](https://www.martinfowler.com/books/refactoring.html). We software developers talk about code smells all the time. We organize working groups and [ensemble programming](https://ensembleprogramming.xyz/) sessions to identify and get rid of them, we read books such as the aforementioned Refactoring and [Clean Code](https://www.goodreads.com/book/show/3735293), and we might even complain to our spouse at home we again had to make a shortcut today because of time constraints, introducing instead of cleaning up a smell. But the software development problems do not end there---technical debt is only the most _obvious_ problem. ## From technical to social debt Technical debt might be annotated with `@TechnicalDebt` in code---I've seen it happen and then happily ignored---but what about social issues in development teams? We all know it severely affects team performance---perhaps orders of magnitude more than a few "simple" code smells you have to work around (or, hopefully, fix). We also all implicitly know a couple of **community smells**: just like code smells, they're anti-patterns that emerge time and time again in (development) communities and negatively effect what the team is trying to accomplish. I really like the terms "social debt" and "community smells", as they perfectly accompany their more well-known counterpart "technical debt" and "code smells". I encountered these words in Damian Tamburri's papers, where he talks about the "shepherding" role of the software architect (or team/devlead, for that matter), who is a negotiator that should try to minimize the effects of both kinds of smells. A selection of community smells identified by his team, from interviewing many practitioners: 1. _Cognitive Distance_; perceived distance between peers on physical/technical/social levels that causes distrust, misinterpretations and wasted time. 2. _Newbie Free-Riding_; newcomers being left to themselves that causes irritation and high work pressure. 3. _Lone Wolf_; "that guy" who commits without taking others' opinions into consideration. 4. _Unlearning_; new technologies that become unfeasible to adapt because older employees refuse to do so. 5. _Black Cloud_; information overload without a clear way to manage it within teams and between teams. These are only a few highlights: there are many more available in [Damian's papers](https://scholar.google.com/citations?user=l7BGAq8AAAAJ). I love these analogies, because it suddenly makes it much easier to _talk about them_! Jumping from code smell to community smell isn't hard, and everybody knows communities don't build themselves. Jessica Kerr goes as far as saying [great teams are "symmathesized"](https://jessitron.com/2018/04/15/the-origins-of-opera-and-the-future-of-programming/). ![](/img/pratoway/1.png "Community work equals a good harvest.") My own findings from [a decade in the industry](/post/2018/10/a-decade-in-the-industry/) and [creating a software company culture](/post/2018/06/over-bedrijfsethiek/) aren't far off: work with people, not technology. That means that when programming in teams, the above community smells should receive more attention than "mere" code smells! Nowadays, most software-centered conferences include a social issues track. There certainly is some attention for social and psychological aspects of software engineering, but not nearly enough. That is the most important reason why I chose to [investigate non-technical skills](/tags/phd) in software engineering education. Damian thinks it is primarily the role of the architect to act as a shepherd to take care of the flock: > We’ve always claimed that architects are much more than just a “technical lead,” but now they must also be an active community shepherd. However, I disagree. I think it is dangerous to explicitly give that responsibility to a single person in a team. Instead, I tend to agree with Jessica's view: the jelling of the team isn't the work of one architect. Rather, it's the accumulated effort of every single person that interacts with the system, and the system that interacts with every single person. Both parts are interconnected, living things. All the more reason for everyone in the team---including non-technical people---to familiarize themselves with the concepts of social debt and community smells. ## Why aren't these concepts well-known? They might be, but just not in those exact terms. Everyone who has read [The Mythical Man-Month](https://www.goodreads.com/book/show/13629), [PeopleWare](https://www.goodreads.com/book/show/67825), or even a few blog posts from [Coding Horror](https://blog.codinghorror.com/) or Dilbert knows this. The Pragmatic Bookshelf apparently is full of [magement, people, and teams](https://pragprog.com/categories/management-people-and-teams/) books, of which most titles are riddled with mysticism and unclear promises (_The Dream Team Nightmare_? _The Agile Samurai_? Or how about simply _Creating Great Teams: How Self-Selection Lets People Excel_?). Even people who don't but work in teams instinctively identify community smells---they just can't put their finger on it. To me, that's the beauty of Damian's work: it allows us to bring the issue to the table and talk about it. Code smells act very much in the same way: they give developers something to talk about. After a while, everyone knows and laughs when someone utters _"what's that smell??"_ when opening up a certain class in their IDE. I am convinced that community smells could have the same effect, or perhaps even a more profound one. For one, I can see it making social issues negotiable instead of staying a taboo. In my own quest to identify the role of creativity in software engineering, we identified _interaction_ as a key component. Less interaction because of social debt equals less creativity. In the end, social debt might very well be the number one reason why projects fail. Gemma Catalino's work builds upon Damian's. This week at ICSE 2021, she presented her team's understanding of [the variability of community smells](https://drive.google.com/file/d/1k083ukTmO3jujgmsx6dLvy3gW8RnxkTV/view?usp=sharing). The paper isn't as powerful as the introduction of the concept itself, but during her presentation, she said one thing that resonated with me: > Communication is the key factor to reduce social debt. So, let us bring the concepts social debt and community smells outside of the academic software engineering circles and inside the development teams in industry: where it belongs and is critically needed. Or perhaps simply scribble `@SocialDebt` on a sticky note and jam it on the back of your peers. Done and done!