Skip to content


November 24, 2013

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.

Friction in SW

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)

10 Comments leave one →
  1. November 25, 2013 04:42 GMT-0800

    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.

  2. November 25, 2013 06:54 GMT-0800

    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

  3. November 25, 2013 14:19 GMT-0800

    Our colleague software architect Ruth Malan (@ruthmalan) left a comment here: Thanks, Ruth.

  4. November 25, 2013 23:20 GMT-0800

    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 🙂

  5. November 26, 2013 06:59 GMT-0800

    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.

  6. December 13, 2013 11:17 GMT-0800

    This seems like an example of “TEAM = SOFTWARE” (see “Dynamics of Software Development”). Where social debt is expressed in the software as technical debt.

  7. January 15, 2014 21:00 GMT-0800

    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?)

    • pkruchten permalink*
      January 16, 2014 09:13 GMT-0800

      Good point Gary. I tended to lump this into technical debt, though. But yes, it could be a 3rd category of friction-causing debt.


  1. Three “-tures”: architecture, infrastructure, and team structure | Philippe Kruchten
  2. The Shape of Code » Pascal, Prolog, Perl, Python and PL/1

Leave a Reply to Kent Schnaith Cancel reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: