Friction
In his 2000 ICSE Keynote in Limerick, Ireland, my colleague Grady Booch said: “There is still much friction in the process of crafting complex software; the goal of creating quality software in a repeatable and sustainable manner remains elusive to many organizations, especially those who are driven to develop in Internet time.” Friction?
“Friction: the resistance that one surface or object encounters when moving over another.” [Merriam-Webster dict.]
By analogy, in software development, friction is the set of phenomena that limits or constraints our progress, therefore reduces our velocity (or productivity). An element of friction that we have been looking at more closely in the last few years is the result of technical debt: the accumulation of design or coding decisions that looked expedient at the time we made them, but are in retrospect suboptimal, and a hindrance now.
But there is another aspect of friction that is not related to the state of the code, but resides at the organizational and social level. Damian Tamburri, from VU in Amsterdam, has introduced the notion of social debt, as a counter part of technical debt [ICSE2013 workshop]. Social debt is a state of a development project which is the result of the accumulation over time of decisions about the way the development team (or community) communicates, collaborates and coordinates; in other words, decisions about the organizational structure, the process, the governance, the social interactions, or some elements inherited through the people: their knowledge, personality, working style, etc.
Social debt + Technical debt => Friction => delays, unpredictable schedule, and/or poor quality.
To reduce friction, we have to work in parallel on both aspects, technical and social. An ideal, frictionless project, would have zero technical friction (i.e., a perfect design, and perfect code), and zero social friction: a team that collaborate, communicate and co-ordinate at zero cost, without error. Like in physics, it is impossible to reduce friction to nothing, to eliminate it, to have a completely frictionless development. But at least it gives us something to aspire to.
Friction in everyday language also means “conflict or animosity caused by a clash of wills, temperaments, or opinions” [Merriam-Webster], and for sure we can witness these often in he social relationships of software development teams, but much of the social debt is more subtle in nature.
As we have defects and code smells on the technical side, we can observe on the social side defects and “smells”: not problems but potential source of a series of concrete problems if left not addressed. Examples of social and organizational and social smells Tamburri identified and studied are: Organizational silos, or Prima donnas [paper submitted to ICSE 2014], maybe not issues in themselves in some circumstances, but certainly a potential for many ills.
Friction resulting for social debt is highly dependent on the context, therefore will vary greatly in form and intensity based on [see Octopus]:
- size of the project (in whatever unit of measure: SLOC, function-Points, person-months, or staff);
- geographic distribution of the development team (compounded by cultural differences)
- governance rules imposed externally (Sarbanes-Oxley, Basel III)
- age of the system (dragging old habits or process form last century)
- stability of the environment (commercial/contractual environment, human resources, etc.)
- business model (internal development, software product, open-source community…)
There may be other aspects of the physics of friction, both static friction and dynamic friction, that could be exploited, making size of the project an analog of the mass, and linear speed to project velocity, and defining a concept of coefficient of friction in presence of various kinds of lubricants.
Your thought?
“Friktion ist der einzige Begriff, welcher dem ziemlich allgemein entspricht, was den wirklichen Krieg von dem auf dem Papier unterscheidet.” Carl von Clausewitz, Vom Krieg, 1832.
(Friction is the one concept that separates real war from a mere paper exercise. My translation)
Philippe Kruchten 
Nice Philippe.
In our work, Craig and me have used the word “learning debt” for short-cuts in learning, lack of improvement and over-specialization (and others). In your description, that might also be a part of the friction then I guess. It seems different than the social debt you mentioned.
The formal kind of social debt (especially standard operating procedures) are based on the premise that standardizing work will increase effectiveness. At best, it increases efficiency, but fails to improve effectiveness when the nature of the development problem changes significantly.
The informal kind of social debt occurs in culture and communication. Separation of concerns, one of the cornerstones of good software doesn’t work as well in development teams. Overspecialization leads to pockets of specialized knowledge, inefficient communication, and a “my problem vs. your problem” mentality.
Better products come from a group of dedicated developers, who pay attention to architecture. Not just the architecture of their software, but also the architecture of their project, development team, processes, and deployment environments.
Software development is a classic “system of systems” and the debt won’t get retired until all of the relationships across all of the systems are accounted for.
Charlie Alfred
Our colleague software architect Ruth Malan (@ruthmalan) left a comment here: http://ruthmalan.com/Journal/JournalCurrent.htm#Friction. Thanks, Ruth.
Awesome followup by Ruth!!
@basvodde I think “Learning Debt” would not be (too) much different than what we conceived as social debt… while the former may refer to, I quote, “short-cuts in learning, lack of improvement and over-specialization (and others)”, the latter refers to organizational or social decisions that led to the current state of things… perhaps it was implicit or uninformed decisions that led to “Learning Debt” as an instance of Social Debt… definitely a venue worth investing in 🙂
There is certainly a sense of breakthrough whenever some constraint on development is removed, measurable in whatever unit of productivity one chooses. That implies more a sense of impetus than momentum, confirming that development is animate. This may be where the object analogy weakens. Animals have mass, but something more. And I wonder whether a development effort has true momentum.
This seems like an example of “TEAM = SOFTWARE” (see “Dynamics of Software Development”). Where social debt is expressed in the software as technical debt.
Another kind of debt (whether you call it social or technical) – the infrastructure needed to run the project efficiently – automated build, automated testing, testing infrastructure, bug tracking, etc. Doing these poorly (which is usually the situation) seriously slows down a project – especially when there is any kind of geographical friction as well. BUT I really do like the “friction” metaphor and have used it at work. It is all those things that slow down the developers from making progress and just applying their energy to the features that provide end user value. And the best managers really get that part of their job is to remove the friction (and the lousy ones that are just engineers promoted without the right skills) do very badly and even make it worse (another kind of social friction?)
Good point Gary. I tended to lump this into technical debt, though. But yes, it could be a 3rd category of friction-causing debt.