Code that has a limited responsibility, with only one stakeholder. Objects and functions that can be part of composition, without being altered. Interactions designed to work even if the implementation details of one actor changes. They will all likely result in code that has not been touched or altered for a very long time. The code is still in use, but as “done” as code ever gets.
It is a blessing when code is allowed to grow stale. We should design our code so that it can slowly sediment, harden by itself, in the peace good design and proper testing creates. The codebase as a whole will still evolve, and that is going fast. Changes to support the business are quickly done in small units with good interfaces. Sometimes a bigger part is swapped out. In other cases, an old trustworthy part is promoted into a library. There is movement where it is needed, but the ripple effects don’t reach far.
When I hear about code freeze or software hardening as part of a delivery pipeline, I think about the aging and maturing of code. With small units of decoupled and well tested code, it will naturally harden. Some files will be created, used for days or decades, and then deleted, without ever being changed. Others will have an eventful youth, but soon settle into being run, but not altered. For me, that is the goal, letting the legacy of code create a solid foundation for new work.
What do you have to change to let your code age in peace?
Comment on the blog!
Create a comment by emailing me. I will then add the comment to the post.Open an email to start writing.