We can only improve upon something if we can repeat it. Every moment of every day, if we can repeat the same steps, we can refine those steps, improving on ourselves.

When we make a recipe, we can use the defined steps. Oops! This needs less salt. It baked for too long. We can improve the steps by making notes in our recipe, such that we can improve it. The refining is the same in the software world, for our making of software.

In the past, I received a series of C++ source files for a project I did not create. The original authoring team was disbanded. The source files included no definition of how to build it or how to apply specific third-party dependencies. It was written for Windows, and the goal was to make it work in macOS or Linux also. As an aficionado of GNU-based building (macOS/Linux/UNIX), I found myself unable to figure out at the time what was needed in Windows-based infrastructure. Infrastructure code is just as important an ingredient as the source code itself.

We can trick ourselves to check off the “infrastructure as code” checkbox if we include CMake instructions (or similar instructions). It’s not enough! Let’s think about other infrastructure we need in our code:

• Automation scripts for grabbing third-party dependencies
• Information about the build machines. This could be defined lots of different ways:
  • Ansible playbooks, to configure a build machine or a test machine (Or other configurations with Chef or Puppet)
  • Dockerfile definition files or configuration files for a container
  • CloudFormation or Terraform files, to configure a small network on the cloud
• Jenkins configuration files, written in Groovy, for a tool to be able to start building a project
• Database data file, for use with tests for some initial construct of testing
• Automation scripts for releasing
• Automation scripts for tagging source code
• Automation scripts for creating documentation (like Swagger, Doxygen, …)
• Automation scripts for packaging an installable product (Windows .msi, macOS .pkg, RedHat .rpm, etc)
• Configuration files for configuring Apache or php
• Pull request or issue templates used with your SCM, to ensure consistency with how you explain changes
• Coding-style configuration file, to ensure consistency of your coding style
• Anything else you can think of. Be creative.

This looks like a long list. Admittedly, not every bullet might apply to each project, but the more of these items we put into our code, the more we can improve upon.