7 ms·

Software Friction

141 points by saikatsg 2y ago

ianpurton 2y ago
The article makes sense. In a way experience is knowing what things will cause friction and having solutions to overcome them. Friction reduction.
WJW 2y ago
> What about event planners, nurses, military officers? As a Dutch ex-Navy officer, we just called this "friction" as everyone had read Von Clausewitz during officer training and was familiar with the nuances of the term. Militaries overwhelmingly address this problem by increasing redundancy, so that there are as few single points of failures as possible. It is very rare to encounter a role that can only be filled by a single person, a well designed military organization will always have a plan for replacing any single individual should they accidentally die.
- staticlink 2y ago
  I suppose the 'bus facor' is not so hypothetical in the military.
  - mro_name 2y ago
    …it may have a different name, though…
    - deleted 2y ago
      [deleted]
- aredox 2y ago
  Also wrt. solutions in the military setting: a strong NCO corp, competent and enabled to take on-the-spot decisions. But it is not "oh, we have solved friction". It trades the "combat" friction of having to wait for orders (possibly compounded by the weather, comms jamming, your courrier stepping on a mine, etc.) and turns it into "strategy" friction of having subordinates taking initiatives they shouldn't have taken. But I'd argue (like modern armies do) the tradeoff is worth it, and the strategic level has more resources to overcome their friction than combat troops engaged in a fight. But it wasn't always the case (cue the famous tale of a Roman consul, Manlius [0], who executed his own son for disobeying, even though he was victorious ). [0] https://www.rijksmuseum.nl/en/collection/SK-A-613 https://www.rijksmuseum.nl/en/collection/SK-A-613 https://www.heritage-history.com/index.php?c=read&author=haaren&book=rome&story=manlius https://www.heritage-history.com/index.php?c=read&author=haa...
  - throwup238 2y ago
    > But I'd argue (like modern armies do) the tradeoff is worth it, and the strategic level has more resources to overcome their friction than combat troops engaged in a fight. I think the tradeoff is practically mandatory for modern armies. The high mobility they require just to avoid artillery strikes and engagements with armor makes top down command impossible to implement in a symmetric conflict.
    - mcswell 2y ago
      I have heard that there is much less of this in the Russian army than in NATO countries' armies--and before that, less in Eastern European countries' armies. The Ukrainian army apparently had to be trained out of that (although IIUC, that training began soon after the fall of the Soviet Union). I'd enjoy hearing any comments about this--true, false, true-but, etc.!
- pjc50 2y ago
  "The graveyards are full of indispensable men" -- attr. Napoleon "I can make a brigadier general in five minutes, but it is not easy to replace a hundred and ten horses" -- attr. Lincoln (exact words vary by source) It's noticeable how few computer wargames simulate any of this, instead allowing for frictionless high speed micromanagement.
  - justin66 2y ago
    That first quote is normally attributed to Charles de Gaulle. [0] I wonder if it would have been in character for Napoleon to reflect on the indispensability of anyone but himself. [0] https://quoteinvestigator.com/2011/11/21/graveyards-full/?amp=1 https://quoteinvestigator.com/2011/11/21/graveyards-full/?am...
  - adrianN 2y ago
    I think we would need better AI to make games where you can only give high level commands enjoyable.
    - WJW 2y ago
      Doubtful tbh, at least in the context of the article. The problem for games that simulate war (or any other environment with "friction") too closely is not that the AI is not good enough, it's that such environments are just inherently not "fun" and thus not good material to make games out of. Games work on a tight gameplay loop where the player can have feelings of agency (they can influence what happens at all) and mastery (they can get better at influencing what happens with practice). For this you need to have a relatively predictable relation to actions and outcomes. Having the game randomly lose the orders you give to a unit without any feedback is kinda the opposite of that.
      - throwway120385 2y ago
        Requiring you to manage a messenger corp in order to dispatch armies past your borders might be a good example of a mechanic that generates friction though.
camtarn 2y ago
The follow-up comment about the Marines' "hot washes" retrospective meetings is interesting. I would love to browse through the Marine Corps Center for Lessons Learned library that's referenced.
AgentOrange1234 2y ago
Nice term and mental model. I hadn’t seen this connection before, but I think I’ll be using this word from now on in a lot of discussions!
pcwelder 2y ago
This is nothing but the second law of thermodynamics. Viewing friction as the principle of increasing entropy helps. You can think of a graph with nodes being the states of various systems including humans, software services, database, etc., and edges being dependencies between them. Reducing the states directly reduces the entropy. Reducing the dependencies reduce the rate of increase of the entropy in the system. This directly leads to various software principles like separation of concern, parse not validate, denormalisation, state reduction, narrow interface deep implementation, KISS, readability etc. All of these reduce friction. As such I find the "Addressing friction" section in the article lacking, but it does highlight some useful points.
classified 2y ago
> Word changes every font to wingdings. (This is a real thing) If the military used Microsoft, America would be in ruins.
- vundercind 2y ago
  The military runs on PowerPoint.
- nicbou 2y ago
  The military runs on PowerPoint, not Word.
twh270 2y ago
Once you're familiar with friction, you start seeing it everywhere. And then you hate how much of it there is. I'm sure there's a philosophical lesson in there somewhere. As far as battling it goes, my experience is that you can get a lot of mileage by just spending an extra minute or three making something a little cleaner, more readable, less prone to failure, etc.
gkilmain 2y ago
A lot of the friction mentioned in the article revolves around tooling. Anyone with more that a few days in an engineering org will witness this. What is not mentioned is human friction. Over simplifying but an engineers job is to write code and push to main. Anything that gets in the way of that I categorize as friction.
hnthrow289570 2y ago
>The requirements are unclear, or a client changes what they want during development. A client changes what they want after development. Agile supports some uncertainty, but often a mile is taken when an inch is given. You have to take it in stride though. Developers stay employed for shipping bad or happy-path-only code all the time. >Is friction important to individuals? Do I benefit from thinking about friction on a project, even if nobody else on my team does? Even if you were to eliminate a lot of friction, the profit would go to the business anyway. The military has different incentives, of course.
- lloeki 2y ago
  > Agile supports some uncertainty, but often a mile is taken when an inch is given. An inch or a mile, over time and with local information only it has you running around in an ant mill pattern[0]. I've seen my share of such projects going nowhere fast. [0]: https://en.wikipedia.org/wiki/Ant_mill https://en.wikipedia.org/wiki/Ant_mill
- zhengyi13 2y ago
  >>Is friction important to individuals? Do I benefit from thinking about friction on a project, even if nobody else on my team does? >Even if you were to eliminate a lot of friction, the profit would go to the business anyway. At the intersection of software development, the military, and whether or not friction is important to individuals... I'm reminded of the USDS, and IIRC some of their work to improve workflows and discoverability around (specific) VA benefits. If you've ever listened to vets talking about the VA, they're rarely complimentary about it, frequently complaining about how hard it is to find the entry point to get the needed benefits, and how hard navigating process is after the entry point is found. Reducing that friction means more benefits are exercised, at a higher cost to the government. OTOH, maybe the overall cost is lower, if fewer phonecalls are answered explaining how to do a thing, and fewer forms are filled out justifying a thing.
ordinaryradical 2y ago
This may be a naïve reading of this, but I’m pretty sure this is a glowing recommendation for choosing the BEAM VM and the languages which run on it.
- edvardas 2y ago
  Can you elaborate on how you made the connection between the article and BEAM languages? I suppose you experienced a lot less friction when working with Erlang or similar, care to share your experience?
  - jiehong 2y ago
    Not OP, but I’d venture to say it’s about supervisor trees
velcrovan 2y ago
I've had some thoughts about this concept applied narrowly to web publishing [1]. It's nice to see a more general theory out there. [1]: https://joeldueck.com/friction.html https://joeldueck.com/friction.html
pavlov 2y ago
This kind of friction is so expansive and ubiquitous that another, less negative word for it is simply “life.” It’s like John Lennon said: “Life is what happens while you are busy making other plans.” Instead of trying to eliminate or stigmatize it, it can be more productive to think of it as a creative input into your static system which can be harnessed for unexpected good. (And personally I would rather live by the worldview of Lennon than a 19th century German general.)
- hinkley 2y ago
  There’s always a nonzero quantity of coworkers who seem to identify too much with our captors (that machines). It’s shocking to them if someone suggests that human errors should be accommodated by a system instead of ruthlessly vilified. That you think you can do something perfectly every time is a topic for you and your therapist. Expecting others do to the same is toxic.
gbin 2y ago
The example about the software updates resonates with me. My policy is usually for the team, if you can upgrade your dependencies, just upgrade now. I have seen so many companies just taking the short term thinking again and again just to realize that oh, now it is too much of a step to update anything let's... Wait? Friction is way easier to take amortized over a longer time so you have to basically bake that in the everyday processes, oh an update? We are not in a bind, just upgrade! It is related to tech debt basically, just avoid accumulating it because it compounds very badly.
- hinkley 2y ago
  We had a hell of a time getting a fix for a CERT advisory deployed because we were several versions behind and there were breaking changes in the way. The idea of rushing a change to make a system more robust is absurd because all of the rushing is your surface area for regressions. Our solution was that at least once a month we had a story to upgrade deps. But as each new person got the assignment they would immediately ask the question, “but upgrade what?” I didn’t have enough information at that point to care, so I told them to just pick something. Our dep pool wasn’t that big and any forward progress was reducing the total backlog so I figured they would pick something they cared about, and with enough eyeballs we would collectively care about quite a bit of the project. Now part of the reason this ranked a story is that we were concerned about supply chain attacks on this project, so it wasn’t just a matter of downloading a new binary and testing the code. You also had to verify the signature of the library and update a document and that was a process that only a couple of us had previously used.
alexashka 2y ago
The friction is people who love power and/or their feelings more than they love the beauty of a world that makes sense. Everything else is particulars.
michaelfeathers 2y ago
I think it makes sense to see friction as disincentive, the opposite of incentive.
closeparen 2y ago
In my experience, the tooling that causes the most friction when it doesn't work is also the most likely to be abandoned, community supported, or only supported by an India team (requiring an overnight for each round-trip communication). Directors and VPs talk a big game about prioritizing developer productivity, but when it comes time to staff a support channel, prioritize a bug fix, or choose who to lay off, it always turns out that they were lying. Thriving as a SWE in a medium-to-big company is not about algorithms and data structures, it is about coping with and recovering from environment breakages, and having the skills to diagnose and fix the environments that you were forced to adopt last quarter and by this quarter are deprecated.
- hinkley 2y ago
  Historically, 90% of my Indian coworkers have had a much higher pain threshold than 90% of my domestic teammates. I can think of two individuals with a low tolerance for bullshit and I always wonder how they fit in socially over there. I have to dig a lot or try to bring a problem into N.A. office hours before I see how much rote work is required to do a task and it’s almost always shockingly high. We write software for a living. Nobody should be running a static run book. We should be converting it to code. I’ve often suspected it’s a job security thing.
  - crooked-v 2y ago
    Keep in mind how immense income disparities are there. For someone living in India, getting a job that exists anywhere at all on the US payscale pretty much guarantees living comfortably and being able to save tons of money on top of that.
  - closeparen 2y ago
    The problem applies to any pair of sites with a 12-hour timezone offset, regardless of culture. PDT<->IST happens to be the one that practically occurs for Bay Area tech companies.
    - hinkley 2y ago
hinkley 2y ago
These physics analogies always fall down on the details. I had a mentor who tried to model story throughput as fluid dynamics which sort of worked but he downplayed the psychological aspects, like the author here is doing. > Friction matters more over large time horizons and large scopes, simply because more things can go wrong. “Scope” is doing a lot of heavy lifting here and I have met so many people who don’t get it that I find it dangerous to sum things up thusly. There’s a nonlinear feedback loop here that is the proverbial snake in the grass. Many people in your org think of incidents per unit of time, not per unit of work. If you have a hundred developers the frequency of a 1% failure mode becomes a political hot potato. When managers or QA complain that something is happening “all the time” they mean it figuratively. I’ve seen it happen for multiple people for an event that happens on average once a month, but one time happened twice in a week, and that seems to be the nexus for the confirmation bias starting. If you have a big enough drive array you will need to order new disks “all the time” and someone will question if you’ve picked a shitty brand because they personally have only experienced one dead drive in their professional life. It’s because humans are terrible at statistics. Now as to the friction of someone leaving to go home (“don’t deploy on Friday”), this also a psychological problem, not friction. The problem isn’t people going home. The problem is people rationalizing that it’s safe to leave or skip a check. They are deluding themselves and their coworkers that everything is fine and their evening plans don’t need to be interrupted. You can have the same problem on a Tuesday morning if there’s a going away lunch for a beloved coworker. Time constraints create pressure to finish, and pressure creates sloppiness, complacency. (It’s one of the reasons I prefer Kanban to Scrum.) Don’t start things you can’t finish/undo at your leisure because you will trick yourself into thinking you have met our standards of quality when you have not. As Feynman said, the trick is not to fool yourself, and you are the easiest person to fool.
zackmorris 2y ago
Don't forget deprecation. Today Apple and AWS (among a great many others) are notorious for unilaterally turning off services that people have built businesses around. The responsible thing to do is to create a new service and then write wrappers that emulate the old service's interface and business logic, before finally turning off the old service at some point in the distant future. But it's more profitable to make a shiny new service and end support for the old one. Capture the profits and pass the costs on as externalities to developers. This may seem like a small inconvenience, but I have watched basically all of the software that I have ever written over a career become unrunnable without significant modification. The friction of keeping up with deprecation has expanded to take up almost all of my time now. In other words, the rate of deprecation determines the minimum team size. Where once 1-3 people could run startups, now it's perhaps 5-10 or more. It's taken the fun out of it. And if it's not fun anymore, seriously, what is the point.
- laserlight 2y ago
  > Today Apple and AWS (among a great many others) are notorious for unilaterally turning off services that people have built businesses around. I'm curious. Can you give a few examples of such Apple services?
  - zackmorris 2y ago
    I probably should have said Apple APIs or libraries. It's been a while since I did macOS/iOS programming, and I got out of it because I got tired of seeing stuff like this: https://developer.apple.com/documentation/assetslibrary/alassetslibrary https://developer.apple.com/documentation/assetslibrary/alas... Looks like maybe they've slowed down on their deprecations a bit: https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-17-release-notes#Deprecations https://developer.apple.com/documentation/ios-ipados-release... https://developer.apple.com/documentation/ios-ipados-release-notes/ios-16-release-notes#Deprecations https://developer.apple.com/documentation/ios-ipados-release... It was rough 20 years ago with the Carbon to Cocoa transition, Objective-C to Swift, CoreGraphics to OpenGL to Metal, etc. Always a moving target, never cross-platform. It's all so opposite to how I would do things. I remember when the US national debt was $3 trillion in the 80s, now that's Apple's market cap. Makes it hard to focus and make rent these days when so many other people are rolling in dough. For anyone curious, with AWS I get notices every few months about some core service or configuration option that's getting discontinued in 6 months. Last year it was launch configurations for ECS (maybe the EC2 portion) that had to be migrated to launch templates (can't recall exactly). A deploy failed before I could finish a large feature I had been working on, which caused me to drop everything, which led to overlapping merges in git and associated headaches that set us back weeks. I should have been ahead of that, but it couldn't have come at a worse time.
jexe 2y ago
Most important point on keeping friction to a minimum is the reduction of moving parts in your app. Find the most architecturally simple way to build, without relying on many third parties or external dependencies. Think long and hard every time you sign up for an API key somewhere. Baroqueness doesn't necessarily win the game.
beryilma 2y ago
The article seems insightful on the surface but falls apart very quickly when you take time to analyze what the author is actually saying in each sentence. Pretty much every statement is a logically false or bad argument or, at least, requires a lot of supporting material to be convincing. Take the following sentences for example. > If people have enough autonomy to make locally smart decisions, then they can recover from friction more easily. Having autonomy has no relationship to recovering from friction more easily. Any why would autonomy cause one to make locally smart decision? The person having the autonomy might be the one causing the friction in the first place and might also be the one making bad decisions. > Friction compounds with itself: two setbacks are more than twice as bad as one setback. This is because most systems are at least somewhat resilient and can adjust itself around some problem, but that makes the next issue harder to deal with. Why would being resilient to one type of problem cause not being resilient to another type of problem? And why would this cause the friction to compound itself? Incidentally, ChatGPT does produce an equally (if not more) plausible article when I ask it to produce an article on software friction.
- noch 2y ago
  Is this yet another essay about software development that does not offer: - Testable hypotheses - Reproducible experiments - Data to support its arguments?
- ranger207 2y ago
  Going up the chain for order is itself a source of friction. Communicating the situation on the ground, dealing with transmission issues like staticky radios, waiting for command to have time to deal with your issue (they may be dealing with other units having similar issues, especially if you have a command structure that doesn't delegate), etc. It's uncommon that higher levels of leadership have a better understanding of what lower level units are dealing with than the lower level unit itself
laserlight 2y ago
Why repurpose a military term from early 19th century, when you could simply call it execution risk?
- ranger207 2y ago
  Well, friction and execution risk aren't exactly the same thing as I understand it, and it's not really "repurposing" the military term as much as it is using it in a broader context than it was originally used in. A lot of military stuff is simply one particular usage of some field: deciding how many subordinates a general should have is a military usage of organizational dynamics; getting bullets from the warehouse to the soldier is logistics; friction is simply a property of complex systems regardless of what the system is
mckn1ght 2y ago
I kinda glossed over the list of suggestions on addressing friction until I got to the games and checklists items. I think that’s really the only way to deal with the moving target that is developing software: regular checkins to make sure things work the way you think they will. The other points are all susceptible to the element of surprise when something inevitably goes wrong. You have to have practiced and internalized the most important parts of your process (shipping and root cause analysis) in order to adapt and respond.
w10-1 2y ago
A small caveat is that the idea of friction suggests resistance to a necessary change, and the concept drives one towards more flexibility and power. In my experience, it is simplification that reduces friction: accepting constraints and limitations, focusing code and architecture. Removing degrees of freedom reduces execution risk exposure. The main feature is the working state: how to keep that accurate, working, and and replicable. Avoid long transactions, splayed-out invariants, backup intervals, complex restart procedures - any exposure to being outside the working state, or in some provisional or pending state.
taeric 2y ago
I am surprised by discussions, so far. Which, at the moment appear to be people poking holes in the shortcomings of friction as a model, and then a few talking about the unreasonable effectiveness of some processes. My surprise is that neither discussion really leans in on the metaphor. Friction, as a metaphor, is really strong as the way you deal with things vastly changes the more mature a technology is. Consider how much extra lubricant is necessary in early combustion engines compared to more modern electric motors. More, as you cannot always hope to eliminate the external cause of friction, you can design around it in different ways. Either by controlling what parts of a system are more frequently replaced , or by eliminating the need for them entirely, if and when you can. You can trace the different parts of a modern car to see how this has progressed. Indeed, the modern car is a wonderful exploration, as we had some technologies that came and went entirely to deal with operator involvement. Manual transmissions largely were replaced by automatic for a variety of reasons, not the least of which was wear and tear on the clutch. And it seems to be going away entirely due to the nature of electric motors being so different from combustion ones?
- nsguy 2y ago
  An electric motor is very different from an internal combustion engine. I'm not sure where you were going with the analogy but an electric motor does eliminate the need to lubricate that an internal combustion engine has (no valves, crankshaft, pistons, transmission etc.). Analogous somewhat to maybe a bad software architecture needing constant care vs. a better one that just works and eliminates a lot of that extra care. I've learned about this term from the economics side rather than the military side. It's all the hidden factors that make things more expensive. Transaction costs. I do think this is a good analogy for "drag" in software development, something along the lines of "technical debt".
  - taeric 2y ago
    Right, that was my point. You can find ways of eliminating some sources of friction in a system, as was done in electric engines. Before you get to the electric motor, though, you will almost certainly have to deal with it in another way. Path dependence being hard to ignore for what we have done to deal with friction in the history of the car. My assertion doesn't lean on "bad architecture," as I feel that there are just different choices and tradeoffs. I do think you should often times look for improvements in the tech you are working with instead of replacements. Replacing tech can, of course, be the correct choice. Often, it is a death knell for the people that are getting replaced. We solve that at societal levels in ways that are different from how you solve them at the local technical choice level.
hermitcrab 2y ago
As a 1-man band my approach is: * Don't promise release dates. * Stick with known tools/libraries/frameworks where practical. * Automate (with comments/documentation) what you can. Checklists for everything else. * Prioritise fixing bugs over adding new features.
dustingetz 2y ago
only hope is to minimize LOC - keep entire system down to 10,000 LOC. Which we don’t know how to do yet (and even if we did, the migration path needs to be solved for too which is a human problem moreso tech)
mcswell 2y ago
Friction comes up--although not under that name--in The Mythical Man Month. (People do still read that, don't they?) One example Brooks gives is the hard drive that goes bad, perhaps losing code, but also preventing people from doing work until it's replaced. (This essay was written about a software project on a main frame, when "the hard drive" was a real thing.) At least that's how I remember it...

141 points by saikatsg 2y ago

The article makes sense. In a way experience is knowing what things will cause friction and having solutions to overcome them. Friction reduction.

WJW 2y ago

> What about event planners, nurses, military officers? As a Dutch ex-Navy officer, we just called this "friction" as everyone had read Von Clausewitz during officer training and was familiar with the nuances of the term. Militaries overwhelmingly address this problem by increasing redundancy, so that there are as few single points of failures as possible. It is very rare to encounter a role that can only be filled by a single person, a well designed military organization will always have a plan for replacing any single individual should they accidentally die.

staticlink 2y ago
I suppose the 'bus facor' is not so hypothetical in the military.
- mro_name 2y ago
  …it may have a different name, though…
  - deleted 2y ago
    [deleted]
aredox 2y ago
Also wrt. solutions in the military setting: a strong NCO corp, competent and enabled to take on-the-spot decisions. But it is not "oh, we have solved friction". It trades the "combat" friction of having to wait for orders (possibly compounded by the weather, comms jamming, your courrier stepping on a mine, etc.) and turns it into "strategy" friction of having subordinates taking initiatives they shouldn't have taken. But I'd argue (like modern armies do) the tradeoff is worth it, and the strategic level has more resources to overcome their friction than combat troops engaged in a fight. But it wasn't always the case (cue the famous tale of a Roman consul, Manlius [0], who executed his own son for disobeying, even though he was victorious ). [0] https://www.rijksmuseum.nl/en/collection/SK-A-613 https://www.rijksmuseum.nl/en/collection/SK-A-613 https://www.heritage-history.com/index.php?c=read&author=haaren&book=rome&story=manlius https://www.heritage-history.com/index.php?c=read&author=haa...
- throwup238 2y ago
  > But I'd argue (like modern armies do) the tradeoff is worth it, and the strategic level has more resources to overcome their friction than combat troops engaged in a fight. I think the tradeoff is practically mandatory for modern armies. The high mobility they require just to avoid artillery strikes and engagements with armor makes top down command impossible to implement in a symmetric conflict.
  - mcswell 2y ago
    I have heard that there is much less of this in the Russian army than in NATO countries' armies--and before that, less in Eastern European countries' armies. The Ukrainian army apparently had to be trained out of that (although IIUC, that training began soon after the fall of the Soviet Union). I'd enjoy hearing any comments about this--true, false, true-but, etc.!
pjc50 2y ago
"The graveyards are full of indispensable men" -- attr. Napoleon "I can make a brigadier general in five minutes, but it is not easy to replace a hundred and ten horses" -- attr. Lincoln (exact words vary by source) It's noticeable how few computer wargames simulate any of this, instead allowing for frictionless high speed micromanagement.
- justin66 2y ago
  That first quote is normally attributed to Charles de Gaulle. [0] I wonder if it would have been in character for Napoleon to reflect on the indispensability of anyone but himself. [0] https://quoteinvestigator.com/2011/11/21/graveyards-full/?amp=1 https://quoteinvestigator.com/2011/11/21/graveyards-full/?am...
- adrianN 2y ago
  I think we would need better AI to make games where you can only give high level commands enjoyable.
  - WJW 2y ago
    Doubtful tbh, at least in the context of the article. The problem for games that simulate war (or any other environment with "friction") too closely is not that the AI is not good enough, it's that such environments are just inherently not "fun" and thus not good material to make games out of. Games work on a tight gameplay loop where the player can have feelings of agency (they can influence what happens at all) and mastery (they can get better at influencing what happens with practice). For this you need to have a relatively predictable relation to actions and outcomes. Having the game randomly lose the orders you give to a unit without any feedback is kinda the opposite of that.
    - throwway120385 2y ago
      Requiring you to manage a messenger corp in order to dispatch armies past your borders might be a good example of a mechanic that generates friction though.

camtarn 2y ago

The follow-up comment about the Marines' "hot washes" retrospective meetings is interesting. I would love to browse through the Marine Corps Center for Lessons Learned library that's referenced.

AgentOrange1234 2y ago

Nice term and mental model. I hadn’t seen this connection before, but I think I’ll be using this word from now on in a lot of discussions!

pcwelder 2y ago

This is nothing but the second law of thermodynamics. Viewing friction as the principle of increasing entropy helps. You can think of a graph with nodes being the states of various systems including humans, software services, database, etc., and edges being dependencies between them. Reducing the states directly reduces the entropy. Reducing the dependencies reduce the rate of increase of the entropy in the system. This directly leads to various software principles like separation of concern, parse not validate, denormalisation, state reduction, narrow interface deep implementation, KISS, readability etc. All of these reduce friction. As such I find the "Addressing friction" section in the article lacking, but it does highlight some useful points.

classified 2y ago

> Word changes every font to wingdings. (This is a real thing) If the military used Microsoft, America would be in ruins.

vundercind 2y ago
The military runs on PowerPoint.
nicbou 2y ago
The military runs on PowerPoint, not Word.

twh270 2y ago

Once you're familiar with friction, you start seeing it everywhere. And then you hate how much of it there is. I'm sure there's a philosophical lesson in there somewhere. As far as battling it goes, my experience is that you can get a lot of mileage by just spending an extra minute or three making something a little cleaner, more readable, less prone to failure, etc.

gkilmain 2y ago

A lot of the friction mentioned in the article revolves around tooling. Anyone with more that a few days in an engineering org will witness this. What is not mentioned is human friction. Over simplifying but an engineers job is to write code and push to main. Anything that gets in the way of that I categorize as friction.

hnthrow289570 2y ago

>The requirements are unclear, or a client changes what they want during development. A client changes what they want after development. Agile supports some uncertainty, but often a mile is taken when an inch is given. You have to take it in stride though. Developers stay employed for shipping bad or happy-path-only code all the time. >Is friction important to individuals? Do I benefit from thinking about friction on a project, even if nobody else on my team does? Even if you were to eliminate a lot of friction, the profit would go to the business anyway. The military has different incentives, of course.

lloeki 2y ago
> Agile supports some uncertainty, but often a mile is taken when an inch is given. An inch or a mile, over time and with local information only it has you running around in an ant mill pattern[0]. I've seen my share of such projects going nowhere fast. [0]: https://en.wikipedia.org/wiki/Ant_mill https://en.wikipedia.org/wiki/Ant_mill
zhengyi13 2y ago
>>Is friction important to individuals? Do I benefit from thinking about friction on a project, even if nobody else on my team does? >Even if you were to eliminate a lot of friction, the profit would go to the business anyway. At the intersection of software development, the military, and whether or not friction is important to individuals... I'm reminded of the USDS, and IIRC some of their work to improve workflows and discoverability around (specific) VA benefits. If you've ever listened to vets talking about the VA, they're rarely complimentary about it, frequently complaining about how hard it is to find the entry point to get the needed benefits, and how hard navigating process is after the entry point is found. Reducing that friction means more benefits are exercised, at a higher cost to the government. OTOH, maybe the overall cost is lower, if fewer phonecalls are answered explaining how to do a thing, and fewer forms are filled out justifying a thing.

ordinaryradical 2y ago

This may be a naïve reading of this, but I’m pretty sure this is a glowing recommendation for choosing the BEAM VM and the languages which run on it.

edvardas 2y ago
Can you elaborate on how you made the connection between the article and BEAM languages? I suppose you experienced a lot less friction when working with Erlang or similar, care to share your experience?
- jiehong 2y ago
  Not OP, but I’d venture to say it’s about supervisor trees

velcrovan 2y ago

I've had some thoughts about this concept applied narrowly to web publishing [1]. It's nice to see a more general theory out there. [1]: https://joeldueck.com/friction.html https://joeldueck.com/friction.html

pavlov 2y ago

This kind of friction is so expansive and ubiquitous that another, less negative word for it is simply “life.” It’s like John Lennon said: “Life is what happens while you are busy making other plans.” Instead of trying to eliminate or stigmatize it, it can be more productive to think of it as a creative input into your static system which can be harnessed for unexpected good. (And personally I would rather live by the worldview of Lennon than a 19th century German general.)

hinkley 2y ago
There’s always a nonzero quantity of coworkers who seem to identify too much with our captors (that machines). It’s shocking to them if someone suggests that human errors should be accommodated by a system instead of ruthlessly vilified. That you think you can do something perfectly every time is a topic for you and your therapist. Expecting others do to the same is toxic.

gbin 2y ago

The example about the software updates resonates with me. My policy is usually for the team, if you can upgrade your dependencies, just upgrade now. I have seen so many companies just taking the short term thinking again and again just to realize that oh, now it is too much of a step to update anything let's... Wait? Friction is way easier to take amortized over a longer time so you have to basically bake that in the everyday processes, oh an update? We are not in a bind, just upgrade! It is related to tech debt basically, just avoid accumulating it because it compounds very badly.

hinkley 2y ago
We had a hell of a time getting a fix for a CERT advisory deployed because we were several versions behind and there were breaking changes in the way. The idea of rushing a change to make a system more robust is absurd because all of the rushing is your surface area for regressions. Our solution was that at least once a month we had a story to upgrade deps. But as each new person got the assignment they would immediately ask the question, “but upgrade what?” I didn’t have enough information at that point to care, so I told them to just pick something. Our dep pool wasn’t that big and any forward progress was reducing the total backlog so I figured they would pick something they cared about, and with enough eyeballs we would collectively care about quite a bit of the project. Now part of the reason this ranked a story is that we were concerned about supply chain attacks on this project, so it wasn’t just a matter of downloading a new binary and testing the code. You also had to verify the signature of the library and update a document and that was a process that only a couple of us had previously used.

alexashka 2y ago

The friction is people who love power and/or their feelings more than they love the beauty of a world that makes sense. Everything else is particulars.

michaelfeathers 2y ago

I think it makes sense to see friction as disincentive, the opposite of incentive.

closeparen 2y ago

In my experience, the tooling that causes the most friction when it doesn't work is also the most likely to be abandoned, community supported, or only supported by an India team (requiring an overnight for each round-trip communication). Directors and VPs talk a big game about prioritizing developer productivity, but when it comes time to staff a support channel, prioritize a bug fix, or choose who to lay off, it always turns out that they were lying. Thriving as a SWE in a medium-to-big company is not about algorithms and data structures, it is about coping with and recovering from environment breakages, and having the skills to diagnose and fix the environments that you were forced to adopt last quarter and by this quarter are deprecated.

hinkley 2y ago
Historically, 90% of my Indian coworkers have had a much higher pain threshold than 90% of my domestic teammates. I can think of two individuals with a low tolerance for bullshit and I always wonder how they fit in socially over there. I have to dig a lot or try to bring a problem into N.A. office hours before I see how much rote work is required to do a task and it’s almost always shockingly high. We write software for a living. Nobody should be running a static run book. We should be converting it to code. I’ve often suspected it’s a job security thing.
- crooked-v 2y ago
  Keep in mind how immense income disparities are there. For someone living in India, getting a job that exists anywhere at all on the US payscale pretty much guarantees living comfortably and being able to save tons of money on top of that.
- closeparen 2y ago
  The problem applies to any pair of sites with a 12-hour timezone offset, regardless of culture. PDT<->IST happens to be the one that practically occurs for Bay Area tech companies.
  - hinkley 2y ago

hinkley 2y ago

These physics analogies always fall down on the details. I had a mentor who tried to model story throughput as fluid dynamics which sort of worked but he downplayed the psychological aspects, like the author here is doing. > Friction matters more over large time horizons and large scopes, simply because more things can go wrong. “Scope” is doing a lot of heavy lifting here and I have met so many people who don’t get it that I find it dangerous to sum things up thusly. There’s a nonlinear feedback loop here that is the proverbial snake in the grass. Many people in your org think of incidents per unit of time, not per unit of work. If you have a hundred developers the frequency of a 1% failure mode becomes a political hot potato. When managers or QA complain that something is happening “all the time” they mean it figuratively. I’ve seen it happen for multiple people for an event that happens on average once a month, but one time happened twice in a week, and that seems to be the nexus for the confirmation bias starting. If you have a big enough drive array you will need to order new disks “all the time” and someone will question if you’ve picked a shitty brand because they personally have only experienced one dead drive in their professional life. It’s because humans are terrible at statistics. Now as to the friction of someone leaving to go home (“don’t deploy on Friday”), this also a psychological problem, not friction. The problem isn’t people going home. The problem is people rationalizing that it’s safe to leave or skip a check. They are deluding themselves and their coworkers that everything is fine and their evening plans don’t need to be interrupted. You can have the same problem on a Tuesday morning if there’s a going away lunch for a beloved coworker. Time constraints create pressure to finish, and pressure creates sloppiness, complacency. (It’s one of the reasons I prefer Kanban to Scrum.) Don’t start things you can’t finish/undo at your leisure because you will trick yourself into thinking you have met our standards of quality when you have not. As Feynman said, the trick is not to fool yourself, and you are the easiest person to fool.

zackmorris 2y ago

Don't forget deprecation. Today Apple and AWS (among a great many others) are notorious for unilaterally turning off services that people have built businesses around. The responsible thing to do is to create a new service and then write wrappers that emulate the old service's interface and business logic, before finally turning off the old service at some point in the distant future. But it's more profitable to make a shiny new service and end support for the old one. Capture the profits and pass the costs on as externalities to developers. This may seem like a small inconvenience, but I have watched basically all of the software that I have ever written over a career become unrunnable without significant modification. The friction of keeping up with deprecation has expanded to take up almost all of my time now. In other words, the rate of deprecation determines the minimum team size. Where once 1-3 people could run startups, now it's perhaps 5-10 or more. It's taken the fun out of it. And if it's not fun anymore, seriously, what is the point.

laserlight 2y ago
> Today Apple and AWS (among a great many others) are notorious for unilaterally turning off services that people have built businesses around. I'm curious. Can you give a few examples of such Apple services?
- zackmorris 2y ago
  I probably should have said Apple APIs or libraries. It's been a while since I did macOS/iOS programming, and I got out of it because I got tired of seeing stuff like this: https://developer.apple.com/documentation/assetslibrary/alassetslibrary https://developer.apple.com/documentation/assetslibrary/alas... Looks like maybe they've slowed down on their deprecations a bit: https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-17-release-notes#Deprecations https://developer.apple.com/documentation/ios-ipados-release... https://developer.apple.com/documentation/ios-ipados-release-notes/ios-16-release-notes#Deprecations https://developer.apple.com/documentation/ios-ipados-release... It was rough 20 years ago with the Carbon to Cocoa transition, Objective-C to Swift, CoreGraphics to OpenGL to Metal, etc. Always a moving target, never cross-platform. It's all so opposite to how I would do things. I remember when the US national debt was $3 trillion in the 80s, now that's Apple's market cap. Makes it hard to focus and make rent these days when so many other people are rolling in dough. For anyone curious, with AWS I get notices every few months about some core service or configuration option that's getting discontinued in 6 months. Last year it was launch configurations for ECS (maybe the EC2 portion) that had to be migrated to launch templates (can't recall exactly). A deploy failed before I could finish a large feature I had been working on, which caused me to drop everything, which led to overlapping merges in git and associated headaches that set us back weeks. I should have been ahead of that, but it couldn't have come at a worse time.

jexe 2y ago

Most important point on keeping friction to a minimum is the reduction of moving parts in your app. Find the most architecturally simple way to build, without relying on many third parties or external dependencies. Think long and hard every time you sign up for an API key somewhere. Baroqueness doesn't necessarily win the game.

beryilma 2y ago

The article seems insightful on the surface but falls apart very quickly when you take time to analyze what the author is actually saying in each sentence. Pretty much every statement is a logically false or bad argument or, at least, requires a lot of supporting material to be convincing. Take the following sentences for example. > If people have enough autonomy to make locally smart decisions, then they can recover from friction more easily. Having autonomy has no relationship to recovering from friction more easily. Any why would autonomy cause one to make locally smart decision? The person having the autonomy might be the one causing the friction in the first place and might also be the one making bad decisions. > Friction compounds with itself: two setbacks are more than twice as bad as one setback. This is because most systems are at least somewhat resilient and can adjust itself around some problem, but that makes the next issue harder to deal with. Why would being resilient to one type of problem cause not being resilient to another type of problem? And why would this cause the friction to compound itself? Incidentally, ChatGPT does produce an equally (if not more) plausible article when I ask it to produce an article on software friction.

noch 2y ago
Is this yet another essay about software development that does not offer: - Testable hypotheses - Reproducible experiments - Data to support its arguments?
ranger207 2y ago
Going up the chain for order is itself a source of friction. Communicating the situation on the ground, dealing with transmission issues like staticky radios, waiting for command to have time to deal with your issue (they may be dealing with other units having similar issues, especially if you have a command structure that doesn't delegate), etc. It's uncommon that higher levels of leadership have a better understanding of what lower level units are dealing with than the lower level unit itself

laserlight 2y ago

Why repurpose a military term from early 19th century, when you could simply call it execution risk?

ranger207 2y ago
Well, friction and execution risk aren't exactly the same thing as I understand it, and it's not really "repurposing" the military term as much as it is using it in a broader context than it was originally used in. A lot of military stuff is simply one particular usage of some field: deciding how many subordinates a general should have is a military usage of organizational dynamics; getting bullets from the warehouse to the soldier is logistics; friction is simply a property of complex systems regardless of what the system is

mckn1ght 2y ago

I kinda glossed over the list of suggestions on addressing friction until I got to the games and checklists items. I think that’s really the only way to deal with the moving target that is developing software: regular checkins to make sure things work the way you think they will. The other points are all susceptible to the element of surprise when something inevitably goes wrong. You have to have practiced and internalized the most important parts of your process (shipping and root cause analysis) in order to adapt and respond.

w10-1 2y ago

A small caveat is that the idea of friction suggests resistance to a necessary change, and the concept drives one towards more flexibility and power. In my experience, it is simplification that reduces friction: accepting constraints and limitations, focusing code and architecture. Removing degrees of freedom reduces execution risk exposure. The main feature is the working state: how to keep that accurate, working, and and replicable. Avoid long transactions, splayed-out invariants, backup intervals, complex restart procedures - any exposure to being outside the working state, or in some provisional or pending state.

taeric 2y ago

I am surprised by discussions, so far. Which, at the moment appear to be people poking holes in the shortcomings of friction as a model, and then a few talking about the unreasonable effectiveness of some processes. My surprise is that neither discussion really leans in on the metaphor. Friction, as a metaphor, is really strong as the way you deal with things vastly changes the more mature a technology is. Consider how much extra lubricant is necessary in early combustion engines compared to more modern electric motors. More, as you cannot always hope to eliminate the external cause of friction, you can design around it in different ways. Either by controlling what parts of a system are more frequently replaced , or by eliminating the need for them entirely, if and when you can. You can trace the different parts of a modern car to see how this has progressed. Indeed, the modern car is a wonderful exploration, as we had some technologies that came and went entirely to deal with operator involvement. Manual transmissions largely were replaced by automatic for a variety of reasons, not the least of which was wear and tear on the clutch. And it seems to be going away entirely due to the nature of electric motors being so different from combustion ones?

nsguy 2y ago
An electric motor is very different from an internal combustion engine. I'm not sure where you were going with the analogy but an electric motor does eliminate the need to lubricate that an internal combustion engine has (no valves, crankshaft, pistons, transmission etc.). Analogous somewhat to maybe a bad software architecture needing constant care vs. a better one that just works and eliminates a lot of that extra care. I've learned about this term from the economics side rather than the military side. It's all the hidden factors that make things more expensive. Transaction costs. I do think this is a good analogy for "drag" in software development, something along the lines of "technical debt".
- taeric 2y ago
  Right, that was my point. You can find ways of eliminating some sources of friction in a system, as was done in electric engines. Before you get to the electric motor, though, you will almost certainly have to deal with it in another way. Path dependence being hard to ignore for what we have done to deal with friction in the history of the car. My assertion doesn't lean on "bad architecture," as I feel that there are just different choices and tradeoffs. I do think you should often times look for improvements in the tech you are working with instead of replacements. Replacing tech can, of course, be the correct choice. Often, it is a death knell for the people that are getting replaced. We solve that at societal levels in ways that are different from how you solve them at the local technical choice level.

hermitcrab 2y ago

As a 1-man band my approach is: * Don't promise release dates. * Stick with known tools/libraries/frameworks where practical. * Automate (with comments/documentation) what you can. Checklists for everything else. * Prioritise fixing bugs over adding new features.

dustingetz 2y ago

only hope is to minimize LOC - keep entire system down to 10,000 LOC. Which we don’t know how to do yet (and even if we did, the migration path needs to be solved for too which is a human problem moreso tech)

mcswell 2y ago

Friction comes up--although not under that name--in The Mythical Man Month. (People do still read that, don't they?) One example Brooks gives is the hard drive that goes bad, perhaps losing code, but also preventing people from doing work until it's replaced. (This essay was written about a software project on a main frame, when "the hard drive" was a real thing.) At least that's how I remember it...