How Friction Slows Us Down
I once joined a project where running the “unit” tests took three and a half hours.
As you may have guessed, the developers didn’t run the tests before they checked in code, resulting in a frequently red build. Running the tests just gave too much friction for the developers.
I define friction as anything that resist the developer while she is producing software.
Since then, I’ve spotted friction in numerous places while developing software.
Friction in Software Development
Since friction impacts productivity negatively, it’s important that we understand it. Here are some of my observations:
Friction can come from different sources
It can result from your tool set, like when you have to wait for gitlab to check out a file over the network before you can edit it.
Friction can also result from your development process, for example when you have to wait for the QA department to test your code before it can be released.
Friction can operate on different time scales.
Some friction slows you down a lot, while others are much more benign. For instance, waiting for the next set of requirements might keep you from writing valuable software for weeks.
On the other hand, waiting for someone to review your code changes may take only a couple of minutes.
Friction can be more than simple delays.
It also rears its ugly head when things are more difficult then they ought to be.
In the vi editor, for example, you must switch between command and insert modes. Seasoned vi users are just as fast as with editors that don’t have that separation. Yet they do have to keep track of which mode they are in, which gives them a higher cognitive load.
Lubricating Software Development
 |
| There has been a trend to decrease friction in software development. |
Tools like Integrated Development Environments have eliminated many sources of friction.
For instance, Eclipse will automatically compile your code when you save it.
Automated refactorings decrease both the time and the cognitive load required to make certain code changes.
On the process side, things like Agile development methodologies and the DevOps movement have eliminated or reduced friction. For instance, continuous deployment automates the release of software into production.
These lubricants have given us a fighting chance in a world of increasing complexity.
Frictionless Software Development
It’s fun to think about how far we could take these improvements, and what the ultimate Frictionless Development Environment (FDE) might look like.
My guess is that it would call for the combination of some of the same trends we already see in consumer and enterprise software products. Cloud computing will play a big role, as will simplification of the user interaction, and access from anywhere.
What do you think?
What frictions have you encountered? Do you think frictions are the same as waste in Lean?
What have you done to lubricate the frictions away? What would your perfect FDE look like?
Please let me know your thoughts in the comments.
