Good topic, which has not been opened enough in software engineering. There is also
This also closely related with Cognitive Dimensions of Notations of Green, T. R. G. , which explains how certain properties of our programming languages contribute to how rapidly we can build software, where viscosity is one of the dimensions.
As for the typo example, I came to the conclusion, that some measures can help avoid renaming. Namely,
- do not "smartly" form variable name from parts
- consider inter-unit references as black boxes (do not look inside)
- (auxiliary) always name inter-unit references at the adequate level of specificity. In other words, don't just use "data", "get_data" as variable name. (this does not solve the API change management though)
I've also found that dynamic dispatch systems (component architecture where component is called "by string") is not a problem for viscosity if the underlying component framework is mature.
Low viscosity is harder to achieve with more junior programmers as especially in the beginning of the project they perceive it as unnecessary concern ("Code works. What else do you want?"). Part of the problem is that they can't really take the abstract advice like in this article to the practical level. (This is true for many principles in software engineering, which require at least some experience before software design/architecture principles are understood).
That is why article like this are important plus it is important software developers develop a habit of making quality software first time because some properties like high viscosity are not easy to refactor later.
See also:
