No sympathy as this is entirely a self-inflicted wound.
The problem is that very few people, at each stage, are qualified to be there. Let’s not kid ourselves with pride and self-congratulatory bullshit about how awesome we are. Most people require several layers of abstractions to do their jobs to cover competencies they should know but don’t both in technology and marketing.
The reason this occurs is because there is no baseline of competence in software, so everything becomes wildly subjective and therefore biased. To solve for that business imposes tools to make things easier, but really it’s to commoditize candidate selection. That eliminates some amount of training costs up front but instead requires a larger labor pool with lower product flexibility. More people of lower competence with far less ability to pivot as requirements change and everything takes longer.
No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before.
> No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before.
I don't want to dismiss this point, because it's real. But there is an alternative.
I've been brought into these talks with other departments before, and I evaluate the tool from an engineering perspective. If they want to use a true no-code solution, we don't block it but raise to the director level that we will under no circumstances support the use of the tool - we are developers by trade and that's what we're paid for, so they are responsible for everything to do with it and bear all responsibility if it fails to adapt.
If it's low code and has an API, we generally much prefer that because it means we can actually deploy and properly maintain the code that might be needed to support integration with it.
We don't copy and paste fucking code and we don't drag around UI elements with if-else statements - it's simply not our profession. You wouldn't ask a carpenter to assemble IKEA furniture. It's a waste of money and time.
So yes, the solutions might "need" a developer, but no sane director would allocate one. It makes no sense.
I work for a low code vendor, and use that ikea example quite a lot. Fact is, most people can’t or won’t afford a carpenter but would rather save time and money by using ikea furniture. I believe there’s a market for ikea software and I believe that there are many organizations that would rather spend money on ikea software than on expensive, slow and scarce software carpenters. And we’re software engineers building the low code platform, so we understand the value of version control, testing, automated deployments and apis…
It's easy to describe this as self-inflicted when you don't understand how large orgs work and have never had to consider how a security team deals with a large org, each piece wanting their own version (or multiple versions) of this solution.
Qualification isn't the issue because we (the US, US tech, SF/NY, etc.) have a lot of qualified talent, both in eng and elsewhere. The issue you describe with competence IS an issue but not for this. Your final sentence is correct but not right.
Basically, you're right and you're wrong and I should probably write something longer form but won't get to it for months. I'll give you an upvote in lieu of that for making me think deeper about the topic.
And after re-reading my first sentence, I apologize for suggesting you don't understand how large orgs work. That wasn't fair and I don't know your background. I'm gonna leave the post unedited for honesty's sake.
> The reason this occurs is because there is no baseline of competence in software
Funny, I actually feel like it’s the opposite - most orgs I’ve worked in have an ultra high bar in specific areas to pass an interview, leaving otherwise proven capable devs who can perform all sorts of projects like this from being hired. It’s like we demand all engineers be doctors to insert an IV.
What gets things done is smaller teams with fewer dependencies. Large teams of highly competent engineers tend to produce massive project scales.
That sounds like something subjective and not a baseline. A baseline is a uniform standard minimal acceptance criteria. Imagine the employer is irrelevant because the technical qualifications are always the same uniform thing, which would be a baseline. It could be specific to technology platform, such as OS specific, Java, web, and so forth so long as it is focused on the technology and not created by a single specific employer.
The problem is that very few people, at each stage, are qualified to be there. Let’s not kid ourselves with pride and self-congratulatory bullshit about how awesome we are. Most people require several layers of abstractions to do their jobs to cover competencies they should know but don’t both in technology and marketing.
The reason this occurs is because there is no baseline of competence in software, so everything becomes wildly subjective and therefore biased. To solve for that business imposes tools to make things easier, but really it’s to commoditize candidate selection. That eliminates some amount of training costs up front but instead requires a larger labor pool with lower product flexibility. More people of lower competence with far less ability to pivot as requirements change and everything takes longer.
No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before.