In search of a better review process

Internal structural engineering reviews suck.

Calculations don’t just exist in a vacuum, they are placed within a context that is meant to be understood by your peers, your manager, and other engineers. If that’s the case, why is it such a pain in the ass to review? Part of it is due to our process and our software.

While our calculation software helps us compute more efficiently, the communication of these technical documents and their contexts is often the real challenge.

The status quo is that current internal reviews are often centralized, large, and cumbersome processes that happen at major project checkpoints. This is often a risky process with the already overloaded senior engineer at the pivotal centre.

To see a better way to go about this process, we only need to take a step into an adjacent industry, peering into the world of software engineering.

There are two fundamental things that underpin the modern software development review process.

• A version control system - a system that helps manage the creation, versioning, modification, and the use of code
• Small, comparison-based reviews that “build” the final project piece by piece

The pivotal technology that enables this is a version control system based on plain text. Catch a quick refresher on plain text here. If we take a step back, we see that we can absolutely apply this to structural engineering and other calculation-based engineering work as well, substituting code for calcs. With that, we can also reap the benefits of having a modern version control and review system in place. This includes things such as:

• More collaborative reviews - engineers end up working together more to figure things out
• Knowledge sharing - an increased transparency through sharing and reviews of calculations
• Better distributed reviews - offload senior engineers and increase junior engineer’s participation in reviews
• Project history tracking - a clear timeline of all the “contributions” that each engineer has made to the project, with the ability to review the project at any moment in time

There are a couple of different ways to actually implement something like this for structural engineers. Here’s a brief list of possibilities:

• Learn to code - do as they do and take full advantage of what the modern software development ecosystem has to offer. Obvious drawbacks include the barrier to entry, the difficulty of communicating with other non-software structural engineers, and the maintenance of the code.
• Use plain text + learn to use git/GitHub - using plain text calculations with a version control system is also another way to accomplish this, leaning heavily on GUI-based platforms instead of terminal ones.
• Stride - building on on top of our markdown calcs platform, we want to simplify git-based version control so that any engineer can use and reap the benefits to the review process and project history tracking.

TL:DR - Version control is cool. Version-control enabled, diff-based reviews are cooler.