The tech scene has largely converged to the understanding that configuration as code is a good mantra.
I wonder when would we embrace the idea of management as code?
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. …
During the past few weekends I was thinking of a problem that came up at work.
Leaving the details out, a decent chunk of the problem has to do with transforming JSON objects dynamically. According to the rules that by themselves are dynamic. According to the dynamic set of rules that themselves have to be expressed in a JSON object.
Given this part of the problem is very much open-ended — and also is not, strictly speaking, 100% an engineering one — I resorted to a TDD approach of assuming certain product usecases would be covered, and designed the end-to-end architecture around this assumption. …
There generally are two good approaches to building data-driven solutions, with a bad one in between.
Good approach #1: Formulate the problem along with measurable metrics, then employ machine learning, and be open-minded at interpreting and acting upon what that machine learning has discovered, however controversial or contradictory it is.
Good approach #2: Decide up front that the problem is too socially-sensitive, and do not use machine learning to solve it. …