- Definition: Stale code
- Cost of old code: noise, entropy and risks
- You need to Trust your tests
- Git examples: looking for stuff
- Git examples: recovering stuff from the past
WIP Alert This is a work in progress. Current information is correct but more content may be added in the future.
If you use git (and any other version-control system for that matter), every committed code change is added to the history.
This means that any code you delete is recoverable from the git history.
With this in mind, you should always be thinking about what code you delete from your projects becase, as we will see below, code in general incurs cost (maintainability mostly) and stale code not only incurs cost but doesn't generate any benefits to your business.
Old, stale code that doesn't deliver any value has no place in your codebase.
Delete it (you can always recover later, if needed)
Definition: Stale code
Compile-time Stale code: Functions/classes/modules that aren't used by any other piece of code (except maybe tests)
Run-time Stale code Functions/classes/modules that could still be called but aren't
- E.g. code to generate a widget that is not being used in any screen in your app
- E.g. code behind a feature-flag that is turned off
- E.g. a library that is not installed by any other project
Cost of old code: noise, entropy and risks
Code is not an asset - code is a liablity
Code itself doesn't really has any value - in fact, it's a source of cost (maintanability mostly).
If you have some code that delivers no value to anyone (i.e. it's never used), it's just dead weight.
These are just some of the problems caused by unused code:
Changes take longer, because developers need to understand the current code before making changes to it. Since there is just more lines of code, it's likely it will take them more time to understand the project.
Broken windows1: Old unused code is a signal to developers that says: "this project isn't that well-maintained". Other developers working on these projects will probably not go to great lengths to write good code ("What's the use? This project is a mess anyway")
Dependency problems: You may get tied to a problematic library just because some old, unused piece of code still uses that.
Test maintainability: Changes in other parts of the code may cause you to need to fix tests for these unused flows, which just increases the cost of change.
You need to Trust your tests
Being liberal with deleting code means that you need to trust that all required behaviour is validated by tests.
Statically-typed languages usually help here because if a required function/class is deleted, you will get compile-time errors.
But even if you have the luxury of compile-time checks to help you, you need proper unit and integration tests to validate that the core behaviour of whatever you are changing is still the same after the code deletion.
Git examples: looking for stuff
TODO add 2 examples
See the full list of things here: Looking for things on Git
Git examples: recovering stuff from the past
TODO add 2 examples
See the full post here: Git examples: Resetting, Undoing and Reverting Things
1: The broken windows theory is a criminological theory that states that visible signs of crime create an environment that encourages further crime and disorder, including serious crimes. (from Wikipedia)