Over-documenting

On over-documenting your work.

In terms of working on a codebase daily, if thereā€™s one thing that I wish Iā€™d done sooner, and also wished that the engineers before and that still works with me, is to over-document everything.

By the statement above, I hope you can already understand what I am talking about. With complete documentation, you can easily find out what a function does, what it returns, what parameters it takes, and what it throws. Itā€™s like a book that you can read and understand.

Some might even call it a ā€œdocumentation-driven developmentā€.

The challenges

But, I can see a few challenges that we might face in order to make it into a reality:

  1. Structure

Itā€™s become a shamble if lengthy documentation doesnā€™t have any meaningful and understandable structure. If itā€™s a novel, itā€™s like you jump to a different act on each page. It doesnā€™t make sense at all.

For this, I personally really favouring the DiĆ”taxis framework. Itā€™s built by developers and really puts developer needs in mind. But, it is still versatile enough to be suited to each team.

  1. Maintainability

Once you have put a lot of ā€œcontentā€ in your docs, maintaining it and keeping up to date with the real system is a challenge. And no, if you think that making autogenerated documentation from the codebase is the solution, itā€™s far from being sufficient (read here to dig more).

For this one, I can only think that habit and discipline are the only key. I might be wrong on this one, but thatā€™s all I got for now.

Published on: