[idoby]

Well, using general Turing-complete code languages for infra and config vs specialized templates/languages is a legit point of contention in the industry right now, although judging by the style, GP isn't considering the pros and cons of each approach, which include:

* Forcing users to learn a specialized language vs reusing knowledge of a general purpose language

* Inevitable Turing-completeness creep and increasing complexity in specialized languages

* Complexity and difficulty of reasoning about general purpose code (and analyzability)

So GP does have a point. He/she is just not making it very well, I think.

[crimsonalucard]

The tradeoffs you mention are obvious right? I'm just sort of downplaying the huge bragging Scarface was doing when he mentioned he did some cloud formation and "infrastructure as code" because it's really not that impressive.

It's obvious that the logical consequence of using Turing complete languages for devops introduce a lot of complexity into infrastructure and can introduce configuration that executes continuously as well. Bugs that only existed in the application layer now creep into infrastructure. Infinite recursion can now be spinning up infinite instances.

That being said the devops thing was a side detail and that's besides the point. The point is that the role 'software architect' is useless.

[idoby]

Obvious? No, and even less straightforward. Personally I think it's a good thing both kinds of tools exist, because each dev/team/project has different needs and different sensibilities.

Personally, I prefer my configuration to be written in a plain-old language (e.g. Python) instead of a specialized config language (be it YAML or JSON based or whatever). I can test that code, I can reason about it, I can review it for bad stuff like infinite loops (not perfectly, but still), I know how it behaves when diffed and merged, etc.

Regarding software architects: I've seen a few companies where architects are hands-off demigods who prescribe complete architectures without ever having to contend with the results of their decisions. Those companies are, in my experience, few, and tend not to do well.

In a lot of other companies, the role of an architect is very similar to what Herr Scarface describes - individuals with a lot of experience who can make broad decisions based on both experience and data, and leave it to lower ranking engineers to work out the exact details. They do the hard/open-ended stuff and come to conclusions about the broad strokes (e.g. "yeah Redis will work well for this problem, but since you have denormalized data you might need a background process to restore consistency"). This is often called "scoping" and it is the main responsibility and impact of higher-ranking engineers (whether they're called "architects" or not, I personally dislike the term).

[crimsonalucard]

>In a lot of other companies, the role of an architect is very similar to what Herr Scarface describes - individuals with a lot of experience who can make broad decisions based on both experience and data, and leave it to lower ranking engineers to work out the exact details. They do the hard/open-ended stuff and come to conclusions about the broad strokes (e.g. "yeah Redis will work well for this problem, but since you have denormalized data you might need a background process to restore consistency"). This is often called "scoping" and it is the main responsibility and impact of higher-ranking engineers (whether they're called "architects" or not, I personally dislike the term).

It seems like these people are capable but most actually are not. The reason is because they spent too much time in this role so they lose the skills of actually being a software engineer and gain the skills of bullshitting about architecture. So when you "interview" or talk to these people it really sounds like they know they're shit when they don't. The reason is, it's basically their job to talk about technology so they become really good at it, and if an interview doesn't involve a technical coding part, then they'll ace those interviews with flying colors.

If you get down to the nitty gritty and literally ask these guys to perform some very easy coding problem or actually implement a product you will tend to see a very high amount of incompetence.

I work at a startup where we accidentally hired one of these architects. The guy bullshitted his way to the top but we're having a hard time giving him a ticket where he works on the actual product. He's politically maneuvering his way around to only work on proof of concepts and holding irrelevant meetings to talk about architecture. Even roped the CTO in to support his case, which completely pissed off the entire team. Startups need people who can get the job done, not someone who can create a little bullshit bubble so that he can keep his bullshit salary.

This is very similar to someone who's been a CTO for many years. If you don't program, if you don't actually build architecture, you lose your technical skills but you gain bullshitting and management skills. This isn't actually completely bad as a companies need leadership and managers and sans the bullshitting part, leadership is a great skill.

It is completely wrong to assume that "Architecture" is some sort of skillset and that an "Architect" is more technically capable (due to the hire rank) than a typical engineer. Give them the title they deserve, and that is: Ex-engineer/manager.

>Obvious? No, and even less straightforward. Personally I think it's a good thing both kinds of tools exist, because each dev/team/project has different needs and different sensibilities.

It's obvious to me the difference between configuration files and turing complete programs or even python. You can extrapolate the benefits of using python or a configuration file. Have you hit an infinite loop error using python to instantiate instances? Maybe once or maybe zero times, but you can still use your brain to extrapolate that this is a potential problem even when you've hit this problem Zero times.

On a side note, you can also extrapolate that JSON and YAML can be turing complete. It depends on how something interprets it. For example:

   {"fib": {
      "PARAMS": {"y": "float"},
      "BASECASE": [["X", "==", 0 ], [1]]
      "RECURSE": [{"EXECUTE_FUNCTION": {
                      "FUNCTION": "fib",
                      "PARAMS": [["y", "-", 1 ]]
         }}, "+", {"EXECUTE_FUNCTION": {
                      "FUNCTION": "fib",
                      "PARAMS": [["y", "-", 2 ]]
         }}}, 
    "main": {"EXECUTE_FUNCTION": {
                      "FUNCTION": "fib",
                      "PARAMS": [["y", "-", 1 ]]
         }}
   }
 

Awkward yes, but I'm just showing you a way where it can be possible in my garbage/made-up JSON above. Which you can extrapolate from that there probably is a much more elegant way of doing it. All you really need are two features: branching and self-reference. JSON or YAML does not actually preclude something to be not turing complete.

>Personally, I prefer my configuration to be written in a plain-old language (e.g. Python) instead of a specialized config language (be it YAML or JSON based or whatever). I can test that code, I can reason about it, I can review it for bad stuff like infinite loops (not perfectly, but still), I know how it behaves when diffed and merged, etc.

Yeah, I'm kind of in agreement with you here as a personal preference.

[scarface74]

While I agree the pendulum goes both ways - for instance a AWS’s CDK builds templates using your language of choice. How can someone know the tradeoffs without a breadth of experience who thinks they can learn everything they need to know from Wikipedia? “There is no compression algorithm for experience.”

[crimsonalucard]

You don't even know how much experience I have. I'm saying architecture patterns can be learned from Wikipedia not 'everything'.

A devops configuration language (outside the domain of architecture) is not included in this category. Please don't be manipulative and please do not lie.