What: Sarah Krasnik shared an idea on the no-code vs sth-as-code debate. She raises an interesting point, namely that “I-as-Code” is “a solution, but not the only one”. To use her words:
“Infrastructure as code is a means to an end. IaC allows developers to version and control infrastructure changes, and developers already code and oftentimes prefer it. But if a UI (for instance, Fivetran’s UI) had all the same functionality but could address the issue faster, would anyone really be opposed? The preference isn’t towards code, but rather a symptom of doubts that a UI could really compete with the versatility of code.”
My perspective: I am with Sarah 100% on the basic idea that this is “a solution” and not the only one.
But I am not at all with her when it comes to the only alternative she is outlining “the UI”. For me, the first step is identifying the right problem, and I don’t think this post does that justice.
The right underlying problem for every single movement to “x-as-data” is a simple one: How do we optimize the flow of a value-producing team. Be that a development team using infrastructure-as-code, or configurations-as-code, or a data team using pipelines-as-code.
The usual answer to that problem is to look into the (lean) manufacturing world to how this is solved there. For a shortcut, we tend to look into the software engineering world which itself is heavily inspired by the manufacturing world when it comes to these questions. And there we will find things like “code”, “versioning”, “CI/CD systems”. But I think it’s easy to forget the true origins of the problem.
Because not everything applies to code, not everything applies to infrastructure. I find it important to always come back to the original problem and ask myself “If I version data, is this going to improve the flow of the team?” If the answer isn’t a definite “Yes” then I am not sure it’s a good (part of the) solution to the actual underlying problem.
Tweet
Share