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". 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 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, a term coined by Kent Beck but really popularized by Martin Fowler's Refactoring book.

We software developers talk about code smells all the time. We organize working groups and ensemble programming sessions to identify and get rid of them, we read books such as the aforementioned Refactoring and Clean Code, 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. 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".

My own findings from a decade in the industry and creating a software company culture 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 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, PeopleWare, or even a few blog posts from Coding Horror or Dilbert knows this. The Pragmatic Bookshelf apparently is full of magement, 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. 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!