With the adoption of values, principles, practices, tools and processes from Agile, Lean, and DevOps, knowledge preservation has become a serious issue because documentation is largely left out.We identify two questions that are relevant for knowledge acquisition and distribution concerning design decisions, rationales, or reasons for code change.The first concerns which knowledge is required upfront to start a project.The second question concerns continuation after initial development and addresses which knowledge is required by those who deploy, use or maintain a software product.We evaluate two relevant approaches for alleviating the issues, which are 'Just enough Upfront' and 'Executable Documentation' with a total of 25 related artifacts.For the evaluation, we conducted a case study supported by a literature review, organizational and project metrics, and a survey.We looked into closed source-code and closed classified source-code.We found two conclusive remarks.First, git commit messages typically contain what has been changed but not why source-code has been changed.Design decisions, rationale, or reasons for code change should be saved as close as possible to the source-code with Git Pull Requests.Second, knowledge about a software product is not only written down in artifacts but is also a social construction between team members.

With an increase in Agile, Lean, and DevOps software methodologies over the last years (collectively referred to as Continuous Software Development (CSD)), we have observed that documentation is often poor. This work aims at collecting studies on documentation challenges, documentation practices, and tools that can support documentation in CSD. A systematic mapping study was conducted to identify and analyze research on documentation in CSD, covering publications between 2001 and 2019. A total of 63 studies were selected. We found 40 studies related to documentation practices and challenges, and 23 studies related to tools used in CSD. The challenges include: informal documentation is hard to understand, documentation is considered as waste, productivity is measured by working software only, documentation is out-of-sync with the software and there is a short-term focus. The practices include: non-written and informal communication, the usage of development artifacts for documentation, and the use of architecture frameworks. We also made an inventory of numerous tools that can be used for documentation purposes in CSD. Overall, we recommend the usage of executable documentation, modern tools and technologies to retrieve information and transform it into documentation, and the practice of minimal documentation upfront combined with detailed design for knowledge transfer afterwards. It is of paramount importance to increase the quantity and quality of documentation in CSD. While this remains challenging, practitioners will benefit from applying the identified practices and tools in order to mitigate the stated challenges.