# About Documentation

# Why do we need good documentation?

Documentation Driven Development (DDD) is a professional approach to building and supporting a quality product at any size organization.

Without documented information, such information needs to be asked from someone. This is not scalable, it slows down the workflow and increases the likelihood of errors.
Documentation aligns common understanding. We have a greater understanding of what we are working on, how we work and why we work in such ways.
If the documentation is poor or not up to date, it increases the likelihood of misunderstandings and errors, that need to be fixed afterward
Knowledge inside people’s minds is fragile, not easily accessible, not easily shareable. As such it’s not really usable and doesn’t contribute to entity value creation.
Anyone can read, understand and improve documentation, but not everyone can read the code, see and understand all product features or production flow without having documentation
Documentation is the source of truth. How do we test and validate the development work if there are no documents to validate it with?
Documentation is needed for users anyway (just called in different terms, like how-to, FAQ, Demos, feature descriptions, etc.), so that work can also already start in parallel with product development.
When we find a better way, approach, tool, workflow, we can update the documentation to realign everyone's common understanding into a new source of truth.
Documentation is a key asset of any company and a crucial part of any Due Diligence process in case of professional investment or exit to sell the company.

Setup so that it enables any individual developer to be independently productive by using the documentation.
Combined with a good Design System as a core part of the documentation: -- A design system is a collection of reusable components (component-driven development, CDD), guided by clear standards, that can be assembled together to build any number of applications.
In general, by writing it directly for an external developer the documentation will be better
It needs to be complete, up to date, and assume no prior knowledge about the setup.
As someone working on product development, you typically read a lot of documentation on many sources, just think of the best places you have seen good documentation and use that as your reference and try replicating their patterns. Learn to avoid replicating the issues what you experience when facing poor documentation

Every aspect we work on needs supporting documentation. We can identify this by needing to ask a question that we can't find an answer to from the documentation. Or then we simply don't understand the documentation itself and it needs to be improved.
The starting point for the first version of the documentation is a question that someone, maybe you, has and it doesn't have an answer anywhere. Each question and answer added reduces the need for others to ask that same question.
If the existing Q&A is not clear enough, via additional questions to clarify and by refining the existing questions and answers to make them more clear. Periodically when refining the Q&A, also the overall structure of the documentation can be improved.

Our Product(s): What are we building and why do we architect it the way we do?
Product Specifications ie. PRD’s (Template)
User Stories with user task flows (Template)
Software architecture
Data architecture (data models and schemas)
Product development flows: How are we building it and why so?
Related assets: What are the assets we use and why do we use those?
Design files: wireframes and mockups
Design assets; logos, icons, fonts, styles, theme, components
Related tools: how we use Figma, Storybook, etc
Programming languages to use and how to use those: NodeJS (for coding backend serverless functions on AWS Lambda) & ReactJS (to build frontend UI app)
Related services; how we use AWS Lambda, etc.
Additional learning resources
Prototyping objectives and outcomes