As an engineer, I think the largest win of configuration as code over the previously existing practices is that we have killed drag-and-drops and other UI-based operations in favor of configuration files.
And when configuration is stored in human-readable files, it allows us to follow best engineering practices, most importantly reproducibility, code reviews, and integration testing.
If some configuration, say, a new environment or a new deployment, has succeeded once, it can be projected to succeed the next time with, ideally, zero extra cost. If some configuration has succeeded at altering the state of three servers, it’s a great start on the path to correctly altering the state of 10, 100, and 1000 machines.
Here I am not saying scaling is a straightforward problem. It never is. But reproducible individual steps most certainly lay the foundation on which it is a lot easier to predictably build large-scale systems.
I think it’s time we, the engineers, do the same to Jira.
With configuration as code as the best practice with us for just a few years, we have collected more than enough data to know exactly what is easy and what is complicated. We know exactly where time is lost, and we know exactly who and how managed to get things done a lot faster than usual.
We no longer live in the world of “I’m a believer in approach X”. The world today is a lot closer to “we know for a fact that approach Y is superior to approach Z”.
And the world of today is a lot more meritocratic, as we don’t have to rate candidates, for example, by how confidently they speak, or by how many configurations they have built in the past several years. Instead, we can accurately judge whether their understanding of the process of building and maintaining production services is correct. Much like algorithmic problems and big-O notation enable us to ask questions with definitively right and definitively wrong answers, in the world of configuration we have dramatically shrink the space where one’s hand-waving and a “strong” resume can take them places; we’re looking at the true substance these days.
Knowledge is the reduction of room for uncertainty, in science, and, especially, in engineering. And with configuration as code we, as the industry, have made a big step forward.
Now, when it comes to project management, imagine if each “permission obtained”, “access granted”, “cross-team dependency resolved”, or some “project successfully derisked by eliminating an unnecessary costly dependency” is no longer a vaguely recalled poorly told story, perceived and judged differently by different people.
Imagine it’s a well-traceable trail of pull requests, each of which visible to all or most of the organization, and each of which can be used later. Either as a reference of how one can best get things done in an effective way, or an example of how lost productivity and wasted time look like.
Won’t this be a magical world?
Let’s make it happen.