Swedish Death Cleaning for your Dev Team
You may not have heard of Swedish Death Cleaning but trust me, it's a thing that exists. Not only is it a thing that exists but it is a concept that might be of value to software development teams.
Swedish Death Cleaning was something I learned about when Marie Kondo made it big a few years ago. Like Marie Kondo, there is a simple mantra to declutter your life/live by. Instead of talking about things "sparking joy", Swedish Death Cleaning asks the question "Who do you think will take care of this when I am no longer here?" While this is a bit morbid, it is something that teams should be thinking about.
Yes, this is a Midsommar reference
I do not bring this up because we worry about people dying on projects. Instead think about team members getting promoted, moving on to other opportunities, winning the lottery, or retiring. The other thing to think about is our memories of things as our memories get fuzzy over time and by time, I mean days and weeks if not hour to hour.
It is important to consider this because the things we build and push into production will ideally outlive our time on that team. Those features and fixes will need to be updated and maintained until the day they move on to the server farm up state. This means that it is part of our responsibility as developers to make lives easier for those who will be maintaining the code.
How do we do this as developers? Think back to the last bit of code you had to update? What would have made make updating that code easier?
One of the best ways to make your code maintainable is automated testing. Ideally you are writing your tests first but some form of automated tests that verifies that your code is working is better than nothing. Refactoring the code later becomes much simpler as the person maintaining the code has a set of guardrails already in place to let them know if they have broken something.
As developers we like to come up with elegant and beautiful designs. These marvels of complexity and elegance can be difficult to understand for those following behind you so one of the best things you can do is simplify your code as much as possible. The real genius of any developer is to make complex things simple.
Another great thing to document would be any upstream or downstream dependencies that your code has and who is responsible for maintaining them. If there are version numbers then documenting those will also make the life of the future maintainer much easier.
Finally a central repository of business rules, dependencies, and environment configurations is a valuable addition to any team. Jira and other work item management systems do not count as those systems can be difficult to search. A SharePoint site full of Word docs and Visio diagrams isn't much better. Wiki's or other lightweight documentation systems are ideal as they are searchable and much easier to find answers in. These systems are also great places to store information about the setup and configuration of your development environments as well.
Finally, all of this documentation is useless if not maintained. Any time you make a change that impacts the documentation, take the time to update the documentation so the information is updated for the next person who makes the change. Out of date information makes everyone's life more difficult.
