Home

This post is sponsored by Sagely, your guide to growth.

The word “elegant” is often employed flippantly to describe a particular class of software solution. Finding a software design book that doesn’t use the term is challenging. Here are just a few examples:

• “Modify the code and the test to make it clear, expressive, elegant, and more general.” - Modern Software Engineering by David Farley
• “The Unix system is a fine example of a powerful whole built out of simple and elegant parts.” - Programming Pearls by Jon Bently.
• “What makes Wallach a good Data General engineer is that he came up with a really elegant subset of those ideas—simple, sweet, cheap, efficient, clean.” - Soul of a New Machine by Tracy Kidder
• “an architect who has to build on a difficult site, or a small budget, will find that he’s forced to produce an elegant design.” - Hackers & Painters by Paul Graham.
• “The trick is first to strive for that elegance, and then, if we can’t achieve it with an appropriate expenditure of resources, to make sure that, if we are forced to a complex solution, it’s because the problem is complex, not just our solution.” - Software Creativity 2.0 by Robert Glass

The consensus is that elegance is highly desirable, but what is it exactly? What makes one solution elegant and another awkward? Authors elude its meaning but rarely explicitly define it. They regard it as Justice Potter Steward regards obscenity: “I know it when I see it.” In this blog post, we’ll explore the concept of elegance in software and propose two quantifiable attributes: symmetry and simplicity.

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.