At a previous employer there was a practice of writing friction logs (via) where we’d try to re-experience the process of getting started with a product. It is hard to believe how many odd, misleading, or buggy things slip into the onboarding process of a living product until you’ve done it a few times. Executives modeled the behavior by taking ~annual “engineercation” where they’d try to hack out a personal project that made use of a product, logging as they went. Especially high-functioning teams would empower the support staff to analyze support inquiries and plan product improvements that would eliminate them.
The biggest value to seeing friction is in product design, in a similar fashion to the TDD claims of improving design. Maybe you can fix a weird form input with a bit of microcopy, but if you zoom out (which can require significant time + resources!) you could redesign the data model and the business process to not even need to ask. I’ve also done this by writing the readme/doc first, and then trying to redesign the code until the documentation doesn’t have to explain and justify so much; I try to whittle it down to a handful of examples that work like the reader would suppose.
I’d say yes. If the friction gets bad enough, it can actually wear you down and affect morale. For example, if a deploy to production involves too many manual actions in a high-stakes environment with lots of opportunity for failure, that means people will start to dread deploying and maybe start looking for jobs at companies that have this particular thing handled better. In another example, if developers don’t have system access to their own machines and need to wait for sysadmin/security to approve and install or upgrade tools for them, that’s another situation where they might decide to leave for greener pastures where they do have enough autonomy to install stuff.
More generally, a team that’s too lenient in allowing friction to persist where it could be alleviated (for example by better automation or increasing autonomy) will face attrition. Worse, the type of people who stick around are the ones who don’t mind the friction or have stopped caring and attract more of the same.
What should we do when we anticipate a high-friction project? I recently finished a project and determined some good practices for data science work. Ongoing endeavors reveal them to only be “good” for a low-friction projects!
Taking Clausewitz’ definition as inspiration, maybe I need a theory that better accommodates some of the causes of friction for projects where they might be expected. I want to address some sources of friction at the “theory” level.
Do we have tools or development practices that are better at handling funky APIs or changing data sources?
How will I structure projects differently when requirements can be expected to change as progress is made?
I like the framing of the balance between handling friction and maximizing efficiency. Don’t just maximize E(output), but minimize its variance.
At a previous employer there was a practice of writing friction logs (via) where we’d try to re-experience the process of getting started with a product. It is hard to believe how many odd, misleading, or buggy things slip into the onboarding process of a living product until you’ve done it a few times. Executives modeled the behavior by taking ~annual “engineercation” where they’d try to hack out a personal project that made use of a product, logging as they went. Especially high-functioning teams would empower the support staff to analyze support inquiries and plan product improvements that would eliminate them.
The biggest value to seeing friction is in product design, in a similar fashion to the TDD claims of improving design. Maybe you can fix a weird form input with a bit of microcopy, but if you zoom out (which can require significant time + resources!) you could redesign the data model and the business process to not even need to ask. I’ve also done this by writing the readme/doc first, and then trying to redesign the code until the documentation doesn’t have to explain and justify so much; I try to whittle it down to a handful of examples that work like the reader would suppose.
This seems quite similar to why you need a wtf notebook (lobste.rs comments).
I’d say yes. If the friction gets bad enough, it can actually wear you down and affect morale. For example, if a deploy to production involves too many manual actions in a high-stakes environment with lots of opportunity for failure, that means people will start to dread deploying and maybe start looking for jobs at companies that have this particular thing handled better. In another example, if developers don’t have system access to their own machines and need to wait for sysadmin/security to approve and install or upgrade tools for them, that’s another situation where they might decide to leave for greener pastures where they do have enough autonomy to install stuff.
More generally, a team that’s too lenient in allowing friction to persist where it could be alleviated (for example by better automation or increasing autonomy) will face attrition. Worse, the type of people who stick around are the ones who don’t mind the friction or have stopped caring and attract more of the same.
What should we do when we anticipate a high-friction project? I recently finished a project and determined some good practices for data science work. Ongoing endeavors reveal them to only be “good” for a low-friction projects!
Taking Clausewitz’ definition as inspiration, maybe I need a theory that better accommodates some of the causes of friction for projects where they might be expected. I want to address some sources of friction at the “theory” level.
Do we have tools or development practices that are better at handling funky APIs or changing data sources?
How will I structure projects differently when requirements can be expected to change as progress is made?
I like the framing of the balance between handling friction and maximizing efficiency. Don’t just maximize E(output), but minimize its variance.
I also think of software friction in terms of inertia. If there is a lot of energy being put in a particular direction it takes more to reverse this.
[Comment removed by author]