Software Safety Procedures are individual, actionable, and auditable processes that can be integrated into a team's existing workflow. The foundation of these procedures are the principles in modern structural engineering that allow submarines, bridges, and large buildings to be safe and maintainable.
Just like bridges, every software application is different. Imagine a construction company saved money by not making detailed blueprints for a high-rise building. Instead, they gave their electricians documents explaining how the future occupants wanted to use each room in the building. Would you feel safe in that building?
That approach sounds absurd; however, that is how most of the software industry operates. Many teams have user stories and flowcharts, yet they still need a meeting to do the equivalent of determining what circuit breaker controls an outlet.
At the start of a software project, a team can answer questions quickly due to having extensive knowledge of the project in their short-term memory. Over time, people move on to other projects or forget some implementation details; gradually, it becomes more expensive to maintain and add new features to even a small project.
SOFSAFE's software blueprint procedure solves this issue by specifying what must be documented for database fields, method arguments, instance variables, and other vital details. Unlike code comments, updating the software blueprint can be done by anyone on the team and doesn't require re-running automated and manual tests due to making a git commit that fixes a typo in a comment. Documentation can be improved over time by the entire team, enabling engineers who are new to a team to make reliable production changes much quicker.
On July 17, 1981, at the Hyatt Regency Hotel in Kansas City, Missouri, 114 people died because a structural engineer accepted a welder's plan via a phone call without performing necessary calculations or viewing sketches that would have revealed severe flaws. The structural engineering world learned from that event. It changed its procedures to require blueprints to be reviewed by a second engineer both on initial creation and when there are changes to a blueprint.
Have you seen a developer verbally propose a solution to a complex problem, and everyone listens and agrees to take that path? That is the software equivalent of what killed those 114 people. That engineering firm had gotten away with not doing blueprint reviews for years, but it eventually caught up with them. Software teams get away with not doing software blueprint reviews for years, but any money saved by that “streamlining” is lost when a major preventable incident occurs.
The first known building standard is from 1772 BC and states, “If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death.” Modern building standards give detailed instructions on making a structure safe, instead of vague statements like “construct it properly.” Modern buildings have incredible long-term structural integrity, fire safety, and maintainability.
Many teams' programming standards resemble the building standards from 1772 BC, with vague statements like “write high-quality code.” SOFSAFE implements programming standards on a per-language basis that give actionable instructions for writing code which results in more reliable and maintainable software.
Have you listened to an engineer explain how various solution components interact to accomplish a user goal? They are telling a story of what causes events to start, where data will go, and what infrastructure will be involved. How many of those stories exist in your organization? Are they being documented? How would you find them, and how do you know they are accurate?
SOFSAFE overcomes this challenge with Tech Stack Stories, which are like user stories but for technology infrastructure. A tech stack story tells HOW technology infrastructure achieves a specific user or business goal. This differs significantly from a tech stack diagram that only documents the infrastructure in a solution.
Modern submarine construction is very similar to software development. Individual modules of the submarine are built-in parallel by multiple shipyards. When a module is ready, it is sent to the assembly shipyard to be combined with the other modules of the submarine. This is only possible because extensive peer review during the design phases verifies that all the modules will work together when assembled.
Like Shipyards, software development teams work in parallel to build individual modules and combine them into the desired software. Peer review of user stories and tech stack stories enables finding issues long before writing a single line of code, reducing burnout, development time, and costs.
How often have you seen a software release pass QA testing, only for the project's business analyst to state, “this isn't what the client needs.” The bare minimum for testing software is making sure the solution is reliable; software testing needs to include frequent verification that the solution is making progress towards meeting the customer's needs accurately. For that reason, the people who plan the software, and have the most in-depth knowledge of customer needs, should be involved with software testing regularly.