In software development, code describes what the program does, but is not helpful when we need to understand what it is intended to do or why. This leads to important quirks that is load-bearing–changing it or cleaning it up actually breaks it unbeknownst to the engineer.
To better understand intent we need comments, documentation, or a formal spec. Describing code that has no intent is also important.
For example, an algorithm implemented using a BTreeSet as a backing data structure, could that be changed to something else? Is there any intent here since BTreeSet preserves insertion ordered and hashable (in Rust)?
See also:
- This tweet from mcclure111 that talks about having to uncover authorial intent many years after some code is written and the concept of load-bearing quirks.
Links to this note
-
Integrating Between AWS Services Adds Incidental Complexity
When using multiple AWS services together new problems emerge—IAM permissions and roles, configuration, and load-bearing quirks.
-
A fence is a man made object that takes cost and effort to construct. They tend to be placed with some forethought as to what they are building a barrier from or to. To remove the fence without understanding why it’s there can have unintended consequences.