Our core claim at bmc::labs is that we offer: solid engineering. sustainable code. We already talked about sustainable code, but what is solid engineering? This article explains how we feel about what engineering in general and perhaps software engineering in particular should be - or in other words, what solid means in this context.

in short

If we wanted to summarize solid engineering in one sentence, it would be: doing things the right way. That is, however, just as vague a description as the term itself, so it isn’t really helpful when it comes to the specifics. What it does is convey two sentiments, or philosophies of sorts:

  1. There is a right way to do things. That doesn’t mean there is only one way, but there are ways which are definitely wrong.
  2. Finding the right way and executing accordingly leads to solid engineering.

There are more principles implied here. The right way usually is right in reference to the problem solved, the audience targeted, or fitting the project timeline. The right way may not be the easier path, but it leads to a better result - again, better in reference to the situation’s performance metrics. The right way is not something that happens only in one’s mind - it can be recognized by fellow experts in the field. To name but a few.

But the question remains: What is the right way™?

the solidity spectrum

When speaking about solid engineering, I like to introduce the solidity spectrum to provide a frame of reference. And to introduce the solidity spectrum, I like to tell the following story.


On the 23rd of March, a JavaScript developer pulled all his code from the repositories of NPM. NPM is a popular package manager for JavaScript, and a lot of software - especially web and mobile applications - depend on NPM to pull in dependencies. If you’re not a software developer, it’s sufficient to understand that software almost never gets written “from scratch”. There is code which is shared across many projects. It is organized in libraries (think of pieces of code as books here) and it is uploaded to and downloaded from package managers.

One of these pieces of code pulled from NPM that day was a small but very popular fragment called Left-pad, and it looks as follows:

module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch && ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i < len) {
    str = ch + str;

  return str;

This very simple and short piece of code takes a string str, a desired length len and a character ch to pad the string with, from the left. It takes "hello", the number 10 and the character '!' and turns it into "!!!!!hello". And, as it turns out, this function was very popular with the JavaScript community.

Why Mr Koçulu decided to pull his code is beyond the scope of this post, but when he did, it broke a sizeable number of other NPM packages which had depended on it. And since everything is automated these days, builds were failing, hairs were torn out, and a lot of people were scrambling to get their web applications to build again.


Ada, named after Ada Lovelace, is a programming language originally designed under contract for the United States Department of Defense. It self-describes as

The Language for Safe, Secure, Reliable Software

and it has the street cred to do so: its original version, Ada 80, became part of the US Military Standard reference manual on December 10, 1980, as MIL-STD-1815. Personally, I’ve seen it used by people working on helicopters, military drones and high frequency transmission systems.

This is what Hello World looks like in Ada:

with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
   Put_Line ("Hello, world!");
end Hello;

The language is strongly typed, has concurrency built in, synchronous message passing, protected objects, all the good stuff. It prioritizes finding errors at compile time and does so aggressively, but also has run time checks against many typical bugs such as overflows, off-by-one-errors, range violations, and so on. There is no package management, but from what (very little) I’ve seen of the Ada world the packages and libraries available online work out of the box. And the people I’ve met working with Ada were some of the smartest, most cautious software engineers out there.

the spectrum

For me, the solidity spectrum is spanned between what leftpad stands for and what decades old Ada projects running satellites stand for.

NPM and the world of JavaScript solve the complex issue of dependencies, and they do so well - it serves a lot of people, and it mostly works. It is very flexible and development is fast, shrinking time-to-market. The cost of this development speed and flexibility is, however, a fair amount of solidity. It is arguably not as critical for web application builds to always run no matter what than it is for, let’s say, a helicopter control system, so the benefits outweigh this cost.

Ada and a few other languages are geared more towards maximum solidity, or at the very least offer tooling which makes it possible to achieve it. They do so in different ways - C++ has coding guidelines and strong best practices, Rust has super strict memory management - but they are united in a few key characteristics: they are strongly typed, they focus on finding bugs at compile time rather than waiting for them to happen at run time, and they emphasise reliability and performance.

our credo

We believe in solid engineering because we think that the importance of long term reliability and performance - or in other words, of efficient computing - will increase in the future. The trends we observe speak the same language: TypeScript extends JavaScript with strong typing, typed languages like Go and Rust are growing fast, and writing good C++ code is becoming a very asked-for skill in a world in which autonomous driving passenger vehicles are bound to become a reality soon. Of course this means that development may take longer and thus be more expensive at times, but we believe that this is a sensible investment into the future.

In terms of electronics and software, we believe in looking at every aspect of a product. We believe in strong partnerships with suppliers and in quality components for a quality product. We believe in well-defined workflows and tooling, and we believe in testing extensively at every stage of development.

Of course, none of this makes us unique. We know that, and we are happy that others share our credo - in fact, we are lucky to have strong partners who share it, and these partnerships improve our outcomes. But as with sustainability, we make solidity one of the cornerstones of our work - because we believe it deserves to be promoted, and because we want our customers to understand that we are committed to deliver reliable results for them, efficiently.

in short: solid engineering. sustainable code.