Software Engineering Standards Document

Introduction

1.1 Purpose

The purpose of this document is to define the software engineering standards to be followed by members of the development team. These standards ensure consistency, quality, and maintainability of the software throughout its lifecycle.

Software Development Process

2.1 Methodology

  • Always build the least necessary. Do not add extra features or quality of life improvements. We only build the absolute necessities to get the product functional.
  • Scope out the work briefly before beginning the development, if it is on the order of hours, a few sentences in slack is sufficient. If it is days, a brief design doc is required.
  • Code review from a senior engineer, and if the branch is protected, it may require ownership approval.
  • Automatic deploy is sometimes used, with GCP and github actions.

2.2 Design and Architecture

    Create a design doc using the following headings where necessary:

  • Context
  • Goals
  • Detailed Design
    • Constraints
    • Architecture
    • Data Storage
    • Alternatives Considered
  • UX
  • Testing
  • Performance and SLA
  • Security and PII Considerations
  • Traceability

2.3 Coding Best Practices

  • For new web projects, start with the skeleton of Flask, Docker, Nginx at Every project should be deployed using Docker Compose. See template at https://github.com/mvpengineerinc/flaskdockernginx
  • While creating project repo, always define a readme file with a set of commands required to run the project. The readme in the reference github has setup instructions to get docker up and running on linux, mac and windows.
  • Always deliver a client project with a loom video demo which shows start to finish all the essential features of that deliverable. When narrating, use the client’s first name to address them.
  • Since we are mainly focused on MVP development, always try to keep the code and time consumed minimal to achieve the desired result. No need to spend time on writing the fully robust code. Do not add new features that are not explicitly requested. This is for both frontend and backend development.
  • When requirements are not clear, always make the nearest possible assumption and start work on it. When delivering, give the assumptions you made in text.
  • Use the black (https://black.readthedocs.io/en/stable/) python formatter to automatically maintain basic python style.