Is your software well documented?
TL;DR: When a software system is not well-documented it is difficult to maintain and more likely to be re-written from scratch. A well-documented software system is comprised of high-level, low-level, user, and developer documentation.
Over the years, I’ve been fortunate to be a contributor on extremely successful software projects as well as not-so-successful software projects. There are several factors involved in making a software project successful, including a bit of luck; however, the constant across all of the successful projects was that they were all well-documented.
A well-documented software system is comprised of high-level documentation, low-level documentation, user documentation, and developer documentation.
The following outlines the four documentation categories mentioned above.
High Level Documentation
- Catalog of externally maintained service dependencies and the considerations (i.e. expected number of concurrent users, uptime/downtime service level agreements) involved in choosing the service including pricing where applicable.
- Catalog of internally maintained services, their dependencies, and define back-pressure.
- Catalog all key stakeholders.
- Operations manual including who to notify when the system is down or broken, how to build, release, and deploy changes.
- Improvement proposals which include links to issues/stories depicting experiments and live implementations.
Low Level Documentation
- API documentation.
- Automated tests (unit/integration/end-to-end).
- Software formatting rules (automatic formatter and lint checking highly recommended).
- How to create and commit a set of changes and a link to the operations manual.
- User manual (HTML or PDF).
- User demos / tutorials.
- REST (or GraphQL or JSONRPC or SOAP) API documentation.
- SDK developer manual.
- SDK examples.
Prolonging the inevitable
In the abscence of well-defined context and scope, your software system is at risk for unbounded scope changes. Software engineering is much about recognizing and managing trade-offs and assumptions. When a software system is not documented it is difficult to reason about the state of the world and this, unfortunately, is where many software systems become so difficult to maintain that they get re-written from scratch.
As a software engineer, I would like to improve daily. This is why I advocate for systems that I contribute to, to be well-documented.