wgroeneveld
/
brainbaking
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

introduce em dash, thanks Rubenerd

This commit is contained in:
Wouter Groeneveld 2021-05-27 10:39:19 +02:00
parent 00e4f1f034
commit 9e89d456c0
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
content/post/2021/05/social-debt.md
View File

@ -10,21 +10,21 @@ The first thing that must have sprung to mind while reading the title of this po
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.
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 effects 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.
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 effects 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;
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/).
@ -36,11 +36,11 @@ Damian thinks it is primarily the role of the architect to act as a shepherd to
> 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.
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.
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.