Documentation

At the right level at the right moment

Bring out your favourite pillow because it’s time for some discussion about everyones most boring topic — documentation. Believe it or not, in the beginning of dev times this was a true and an important deliverable.

Documentation was (and still is in some industries) a separate profession. What's the purpose nowadays? Of course to make it easier for developers to understand how the application works, before changing it, and without the need to spend weeks trying to backwards engineer code.

I’m going to be super blunt in order to save your time. There is really no need to have detailed documentation anymore. If you are using standard frameworks, these are already documented by whoever is maintaining them, and that alone takes you far. Secondly, no one will read it. Sorry, they won’t.

So it's a much better idea to focus on documenting parts of the code which are complex, contains heavy business logic and which performs some important function in your application.

A 3-5 pages long document describing the functionality in a high level way, with details about statuses or what it may be — will be read because it's comprehensive and easy to grasp quickly.

All documentation needs to be maintained, so once you are done coding some complex logic for a feature, it's a good idea to brain dump down the most important things about it. You will thank yourself later.

Read more in "The CTO Playbook" available on Amazon/Kindle.