* 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.
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.
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.
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).
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.
You're implying that my comments are stupid and arrogant. Prove it if you can, let's get to the bottom of whether or not "architects" is a worthless specialty or not. I think you know I'm right and the only thing you have left are personal comments on my intelligence.
We all thought we were the smartest people in the room at one point, you’ll grow out of it too one day.
Again with the insults.
Why bother? Because you can learn and I can learn. I don't come here to trade insults. I come here to lay down the actual reality of what I see unimpeded by social norms. Yeah I'm sure I touched nerve here, but it's nothing personal, the internet allows me to talk about truths that are uncomfortable and forces me to face those truths as well.
I've been proven wrong tons of times on HN, so I'm hoping that if you disagree, you can prove me wrong and I can learn something and I'll return the favor in turn if you're the one that's actually wrong.
I find that this isn't the case with most people, they don't want to face reality. The fact that you turn to personal insults and have this whole "why bother" attitude seems to me as a cover. You don't bother because you got absolutely Nothing to offer.
As software engineers, we tend to be told especially when we are young that we are all “smart people” (tm). We start to internalize it (believe our own bullshit). But the longer your career is, you realize that the world is full of “smart people” and that your coworkers also came up thinking they were the smartest people in the room.
You don't even know how old I am, you don't even know what level of intelligence I consider myself to be. Yet you make a bunch of baseless comments hinting at my personal character. That is the extent of what you're trying to convey, an insult through and through yet subtle on many levels. Politics, the only essential skill needed to become an architect.
When did I say you can learn everything you need to know by reading some blog posts or Wikipedia? I never said this. I only said that you can do this for 'architecture' and that's why the job role 'software architect' is complete bullshit.
Now let's get back on topic. You disagree with me. You think architects know something about 'architecture' that is beyond Wikipedia and blog posts. Prove it. You think they have some ability that sets them apart from normal engineers. Tell me what that is and why there exists articles like this:
http://www.realfreemarket.org/blog/2012/09/13/never-trust-a-...
I don't want to see another irrelevant comment because that just tells me that you got absolutely nothing left. Prove the worth of a software architect.