Why does the Software Development Standard matter?
How does one solve a specific problem, such as creating a Spring Boot module? Are there any company conventions or enforcements?
These questions often come up from developers. This is where software development standards can help. A developer can follow the document to solve the problem asynchronously, rather than always requiring verbal sharing. In the big picture, delivering quality software is a goal. The software development standards can be used as a tool to ensure that every project can benefit from common knowledge.
Maintaining a consistent format for software development standards is considered good practice, as it is clear to read and ensures the comprehensiveness of the information provided.
Title
The title of the software development standard serves as the document’s name, clearly indicating its purpose and scope. It should be concise, yet descriptive, providing an immediate understanding of the standard’s focus. The title is a noun phrase. It represents a concept or an action.
Header
The header section includes essential metadata about the standard, facilitating proper management and tracking. Key elements within the header include:
- Authors: The names of individuals responsible for creating and maintaining the standard.
- Created Date: The date when the standard was initially established. Format: yyyymmdd.
- Version: An identifier indicating the version of the standard. We simply use the date with the format yyyymmdd, for example, 20230117. The version will always be increased whenever there are changes after it becomes official.
- Status: Current status of the standard. The default statuses include Draft, In-Review, and Official. If a standard is archived, the status should be changed to Obsolete, with an additional element, ‘Obsoleted By’, added.
- Next Review Date: The scheduled date for the next formal review of the standard. A reminder should be sent to relevant stakeholders on their calendars (i.e., Outlook).
- Keywords: The category or scope of the standard.
Table of Contents
The table of contents provides an organized list of sections and subsections within the document, allowing readers to quickly navigate and locate specific information. It also acts as a roadmap for the content covered in the standard.
Values
The values section articulates the core values of the software development standard. Values represent the fundamental beliefs or the “why” of the standard.
Principles
The principles section outlines the guiding principles that govern decision-making and actions. These principles provide a foundation for making consistent and aligned choices. In other words, principles represent the “what” of the standard. Principles act as the bridge between Values and Practices.
Practices
The list of practices represent the specific guidelines, methodologies, and processes recommended or required by the standard. This section delves into actionable steps and methodologies that we should follow to adhere to the established standards. In other words, practices represent the “how” of the standard.
Change history
The change history section documents the evolution of the software development standard over time. This section is crucial for tracking the document’s history and understanding how it has evolved.
It includes:
- The date of each revision
- The version number
- A brief description of changes made
- and, the individuals or teams responsible for the modifications.
1 comment