31–40 of 334 posts
I note there is - strangely - no corresponding "Citizen Management Consultant" role.
https://www.gartner.com/en/information-technology/glossary/c...
BASIC was an attempt to allow people to write software in what looked like English, and indeed it was extremely successful (cf. Visual Basic). The language designed to look like English was COBOL. BASIC looked nothing like English. The reason it became popular was because you could develop programs interactively - edit, run, load, and save programs - without ever leaving the system. It was still programming, though (…
This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…
To play devils advocate, isn't the idea with Ansible at least that it's idempotent. The YAML should describe the final state and should be concerned with branching or lower level features like that. (It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)
Thus, it is very easy to get in a situation where an Ansible playbook applied against two machines with slightly different production history will result in very different behaviour.
If you want real declarative configuration management, try Nix/NixOS.
I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas." And that's how I view my job as a software developer: clarifying ideas. Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools…
I work at a large non-profit. I'm not a coder, but I'm IT literate, and know enough about database design to not do absolutely stupid things. I'm happy to document processes enjoy clarifying ideas.
We use Sharepoint. In many many respects Sharepoint is detestable garbage, but I have managed to create some really quite complex automated workflows which are saving people in the organisation a lot of time, using Sharepoint Designer (no coding). It's documented, fairly robust and I wouldn't have been able to write it in a conventional language.
Earlier quoted context omitted.
To play devils advocate, isn't the idea with Ansible at least that it's idempotent. The YAML should describe the final state and should be concerned with branching or lower level features like that. (It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)
There are plenty of declarative programming language families. Lisps, MLs, SQLs. Configuration is code. Use a programming language.
What would be the benefit of adding a declaritive language into the mix over YAML?
in most businesses the business experts are more expensive. wasting their time with building systems can be costly
Last couple of years? I'm sorry, how long have you been in the industry because the industry has talked about that forever.
I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential archi…
Nearly 40 years for me; I remember reading about The Last One [1] back in 81. [1] https://en.wikipedia.org/wiki/The_Last_One_(software)
Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use.
The language was COBOL.
Oh, and look, this one still seems to be around: http://www.makeyourownsoftware.com/
The idea isn't new. I first saw it as '4GLs', which were higher-level languages. Later we had rule engines and now AI. Programmers never go away, though. Besides the need to write the customizations that the higher level languages miss, there is the need for disciplined thinking and testing. No matter how simple the tools become, the need for these remain.