This first principle is about streamlining the upfront stages of the software development lifecycle that precede actual development. In traditional software projects, the requirements collection and Design Phase usually account for a big time and effort investment. Part of the reason why custom software projects take significant effort and time is because of the sheer amount of documentation that must typically be created (and reviewed) by both business and technical stakeholders, and this work is time-consuming and complex. These documents can often be fairly technical and use specialized notations to support custom development because they are meant to facilitate the translation from the original business intent down into detailed, lower-level concepts (ultimately being translated into lines of code by developers later in the software lifecycle). The sheer volume of documentation can also result in "losing the forest for the trees," making it easy to obscure the overall understanding of the application and overlook important gaps or missed requirements.