I had a wise friend tell me that engineers are always in a state of being wrong. What you build today you will most likely laugh at in five years. The goal for today is to build the least wrong thing you can.
I used to argue more than I should have simply because I didn't like being wrong either. After hearing this, it helped me to become more objective.
My problem is that the least wrong thing I know of is very different from all existing processes, and take more time and money than most are willing to stomach.
Indeed, but then there is, "using a query language designed for data analysis in event sourced systems to: read, parse, version, and write system and configuration files instead of using VCS like Git" levels of wrong, and sales/marketing professionals in charge of the system wrong.
Time is measured in quarters, money is measured vaguely by proximity to sales.
Thought using excel as a database was bad? Try working in a system where strings are `eval`ed in SQL, and every state change is stored in intermediate or virtual tables, then thrown away, so no actual version control is taking place; just diffing and merging Unix configuration files.
Why not use diff and patch? Takes too much time and money, they only know SQL.
