Documenting the past

My team is currently in the process of documenting a project we inherited. The project was a skunkworks effort and documentation wasn’t as important as proving that it works. The developer who wrote it is no longer on the project and isn’t the most pleasant person to interact worth so we are on our own. The interesting thing about this exercise is we are realizing how much lack of documentation cost a project.

The number one reason for documentation is so another developer can step in and keep the project running if you are hit by a bus, falling piano, or UFO. The big motivator for us is code refactoring and removing dead code becomes very hard without proper documentation.

I was watching a presentation by Jack Diederich on code reduction and one of the reasons he often hears against removing dead code is “It might be used…somewhere.”

As he points out when using a dynamic language it can be very hard to identify if code is called or not. He recommends adding a comment to indicate where code is called from. Using code coverage tools does help identify dead code but you need to have a full understanding of the use-cases or else you may accidentally remove code that addresses an edge case.

Documenting legacy components can be seen as an expensive part of a project but will ultimately reduce technical debt and save time later on.

Leave a Reply