The Mutability Tax – David Morgan

After a few months in a project, we find a nasty bug: for some reason, the data the input data does not match what we have in our databases. This starts a long process of debugging and numerous print statements to find the culprit: we had a function with side effects that slightly changed the input data. Hours were lost because we stated at the start of the project that our data is mutable, which means that after creation anyone can edit it. This phenomena is called “Mutability Tax” and David Morgan has a great definition for it:

Systems having loosely coupled modules that pass mutable data between them pay the mutability tax. They rely on convention and luck to avoid severe, hard to reason about bugs due to unwanted side effects of mutation. As these systems get larger and more complex, their luck runs out, and maintenance cost increases.

In this article by David Morgan, he explores mutability vs immutability in Dart and the best practices for creating immutable classes in our projects using code generation with the built_value library: The Mutability Tax – David Morgan

Leave a Comment