They use AppBuilder 2.
The flaw in your argument is that you're assuming the business grows while AppBuilder remains the same, or even just grows less quickly. There's no reason to think that would be the case. Scaling is a problem that Google and Amazon have really worked hard at solving. Plus for every business that outgrows AppBuilder there'll be 100 that don't, which still represents a huge contraction in the need for developers.
Automated code generators are coming, and they're going to be really good at writing code. If your job is writing code, learn to do other things as well.
Wordpress, Wix, Access, Oracle Applications, etc. were all thought to solve the problem of development expense and they have all failed. I mean they get some coverage, but once a business grows in complexity, they quickly become obsolete, or in the case of larger apps, configuration is more complex and error prone than developing the application.
They probably don't pivot very well either. Maybe Google will figure it out, but I don't think they will.
I don't know better solutions for developing RAD (rapid app development) apps for companies who are running on the Microsoft stack and who don't have dedicated dev teams.
Now for them Google App Maker is a very interesting solution.
Actually Google addresses these kind of users explicitly in their early access application form.
I don't think that this platform was intended to replace Frontend Development, React, Angular, etc
We have inventory control systems that have their own database server (including disk format, their own indexing system, ...), own query language (because, ... euhm ... needless to say, someone wrote a script that dumps their own database into a mysql, and deletes and rebuilds the mysql every 2 hours, and everyone uses that to query the data. These days, even including the team that built the product). Impressive code (or I should say, impressive that it doesn't burn down our data more often). The point of doing/having done this ? It makes everyone's life more complicated, which seems to mean more reason to promote the participants.
Of course, failure of designs and over complicated designs is always seen as a reason to do more design (every postmortem, every time), with more anticipated future evolution, instead of less. Better and more accurate product managers, better and more accurate requirements (that are never going to come). I shudder to think what happens after rewriting databases from scratch has become the norm. More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving.
The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it.
Cynicals say that this is simply "CV-first engineering". Of course the database system for your company ticketing system needs to scale to 50000 employees, and 1 billion customers, never mind that you have 10 at the moment. When you go and interview at Google/Facebook/Amazon, and they ask you "what have you built", are you going to answer "a system that works really well for our 100-person 500-customers company" which runs really well on a single cloud server. They'll laugh you out of the room. (of course reality is that no, they won't laugh you out of the room)
> Designs don't ever match up with real world requirements (they match up very well to stated requirements).
Perhaps the most important discipline in computing isn't anything related to technology, but is instead "requirements analysis". What does your company generally use to communicate and record requirements - use cases/stories/other? Are we just still struggling with the same old problem - data can be modeled easily, but not complex behavior?
> More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving.
Do you think these people don't know their own requirements because: aspects of the complex underlying real-world problem or system are difficult or unknown to them; they are trying to describe something new in their imagination; the mechanism for writing the requirement is vague meaning it inevitably needs to be further decomposed; something else?
> The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it.
How do proponents of these "custom" database engines justify them if they are not really needed? Is management clueless?
Then they just find an off-the-shelf solution (SaaS most likely) to replace it.
> Seems like it's kicking the issue down the road and accumulating technical debt along the way.
If you do a ground-up rewrite or find an off-the-shelf solution then technical debt doesn't matter anyway does it?
If something takes a long time and may not work, that's when it's risky.
Sometimes this is truly justified (especially when the code comes from a $2.50/hr "coder" off Upwork), but more often it's just people wanting to do things their own way and not deal with the cruft of another thing.
