Home

Consider this ostensibly innocuous number sequence:

Take a few minutes and try to divine the 5th number.

Don’t feel bad if it’s not immediately apparent; you’re looking at the Busy Beaver sequence[^busy_beaver]. The 5^th, and all subsequent numbers, have eluded the world’s best and brightest mathematicians and computer scientists since its inception. The mystery is rooted in the growth rate: it progresses so fast that no computable function can keep up with it. Follow along for a fascinating foray into the limits of computability.

Welcome to the second installment of this two-part blog series on creating robust automated testing and local development solutions for MSSQL. If you haven’t read the first post yet, please do so before proceeding (Testing and Local Development with MSSQL (1 of 2)) as this post builds upon concepts introduced there.

This post aims to guide the reader through creating a custom MSSQL container image with an embedded database and schema. While the process outlined in the first post works well, it’s not efficient. Each container initialization requires connecting to the target database, generating a DDL script, and executing the script inside an MSSQL container. Each local development machine and build server need the same container, and there is no need for each of them to duplicate the initialization process. Shifting those responsibilities to an image build step eliminates the repetition. As a bonus, using a base container image obviates the need for every entity using the container to have access to the target database.

The most challenging part of designing an effective automated testing strategy is accurately simulating databases. Microsoft’s SQL Server (MSSQL) is particularly irksome because of its large footprint, lengthy startup time, plethora of configuration options, ability to store custom logic (stored procedures, user-defined functions, …), and exorbitant licensing fees. These characteristics make it onerous to materialize production equivalent instances within automated pipelines efficiently. This post is the first in a two-part series demonstrating a technique to assuage said difficulties.

Procrustes, the son of Poseidon, enticed weary travelers into his lair with the promise of sustenance and a night of sleep in an extraordinary bed. The bed was purported to be a perfect fit for all who laid in it. Once situated in the bed, Procrustes delivered on his promise by either hammering and stretching or amputating the feet of the victim in order to match their stature to the bed. The end result was always death. Theseus finally ended Procrustes’ reign of terror by forcing him to lay in his own bed. The myth of Procrustes is a perfect analog for modern day software engineering.

Organizations often attempt to define software engineering tenets (aka core values or principles) that serve as a static mental and behavioral model to guild employees. Tenets are a powerful tool capable of inspiring people toward a common goal. However, poorly designed tenets can just as easily unite a community on a myopic quest toward inefficiency.

Tenets are essentially a simplified model of a problem space that reduces the cognitive load associated with decision making. The intent is to provide a shorter path to a good decision. These models often become a deeply ingrained component of engineers’ psyches which are subject to the human proclivity of self-defense. Unfortunately, models that are overly-simplistic or inaccurate provide a shorter path to a bad decision that may be defended with disregard toward reason. This is why it’s important to avoid tenets that promote silver bullet thinking or preclude reasoning from the engineering process.