Documentation Driven Devlopment

While brainstorming for new projects, I’ve been doing a kind of personal retrospective from the last year(s).

Building a product is hard. Building a new product from scratch is even harder, especially when the resources are limited. Building a product that will be used or that will be set up by developers comes with some extra tasks. One of them is public documentation.

On a team where the project is constantly changing, and the scope is only the quick view of what you want to achieve, development and documentation can be tricky.

You can’t start coding until you fully understand the ultimate goal of your feature, and you can’t write proper documentation if you don’t understand what you are building either.

Ok, in a perfect world with unlimited resources, a team would have someone dedicated to documentation, but that’s not the reality for many startups.

During this last year, while working on a feature that had very little information (scoping). I had this idea, that when things are not clear, an engineer should start with documentation. A documentation-driven development if you like.

Writing and explaining first what your feature does will give you clarity, you will get reviews from Product or your peers, and mainly you can get alignment if this is what you should be working on. If it isn’t, other conversations need to happen to clarify things.

I have used this method once. It did help me. I was lost on a feature I was working on. Starting to write about it brought me so many questions, and, at the same time, I was doing the public documentation that was still needed and part of the project.

This method seems to be used in other places. If it’s a fit for your, will depend on your team and company needs.