I once worked with a guy who embodied the "grumpy old man" (we were both just out of college btw) attitude for every new, cool thing I brought to his attention. I kept telling him that in order to stay relevant as a programmer in the foreseeable future he would have to stay on top of technology and keep his chops up outside of the very mundane engineering work that we did at that company. He would flatly refuse out of hand and say things like "Someone who only knows COBOL for 40 years will still have a job". It frustrated the hell out of me at the time, but he's probably right. Not saying you're guaranteed a great job or be making google-level salaries, but you have to try pretty hard to become completely irrelevant in technology. There's a huge long tail of boring business coding that happens every day, and that world as an aggregate whole doesn't change very much.

If you have even enough interest to be on this website and explore things like App Maker and question things like this, you're going to be just fine :)

I have a colleague, a graphic designer who is nearing retirement age. Every time Adobe announces a new software tool, she's partly excited, mostly terrified. Adobe likes to show how newbie-friendly these tools are. One click here, another there, and...project is done. She pays money to visit these demonstrations at conferences. Then she watches on, imagining her billable hours being redirected to an intern, the client's nephew or someone like that.

Usually the terror gets a sort of beachhead in her mind, and for a while my colleague bears the cognitive cost of this "well there's no need for me anymore" anxiety. It's really sad to watch.

> There's a huge long tail of boring business coding that happens every day, and that world as an aggregate whole doesn't change very much.

This is so true. I wish everyone fearing for their career due to new tech could understand it. Braided into a broader whole of business process you've got huge loads of necessary mental capital too, like the ability to deliver on multiple deadlines, the ability to set healthy boundaries, set proper budgets, and communicate well with others. My colleague has all these things; if only she could see new technology is only a small part, and overall a very forgiving part that needs humans like her more than we might think.

I'm afraid that the new generation of low code solutions are not just "form" builders or prototyping tools. We've built a full operational system and client facing portal using a low code solution.

Her customers are the people who want someone to "make this work" and who don't want to mess with it themselves any more than they want to buy a big chest of tools and do their own vehicle maintenance.

Her customers are not the skilled amateurs now getting better tools. Her customers are the business people who already have too many things to do and aren't looking for ANOTHER project to add to their plates.

edit: minor phrasing

Not at all actually. There is a ton of demand for light code app builders (waves hand) for simple CRUD stuff in most businesses. These apps are usually cost prohibitive to build and maintain, so things App Maker make a ton of sense.

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?

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?

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.

COBOL is such an excellent high-level abstraction from the computer hardware that it's almost pseudo-code and one can translate business requirements very easily, but therefore working in nothing but COBOL isolates a developer from underlying technology and trends.

I wrote a few algorithms in COBOL, basic sorts and trees, which was really awkward and whilst it can be forced to do other tricks such as data compression and encryption[0] it's really not conducive to such tasks. As a result it's easy to sit in a COBOL-bubble writing IF...ELSE business code all day long and not do anything computer-sciency until the memory and skills fade.

Thankfully my COBOL programs called down to C programs to do nitty-gritty work otherwise I'd probably have been pigeonholed both in skills and career; many companies seem to ignore COBOL experience as 'not proper programming', for the reasons above. However being one of the few people dealing with the old COBOL code gave me huge experience in working with the business clients.

[0] we had one vendor offer us AES-in-COBOL for scary amounts of money.

Many companies used to run cobol bootcamps to hire developers. As recently as 2004, one local company was still doing them here. Very few of their developers studied cs in school. The boot campers studied who knows, and those who studied computers often majored in cis or mis.

So you can see how those people are really starting off at zero when it comes to switching to more modern dev stacks. I've personally seen very few make the transition.

My first paid dev job was at such a place, doing mainframe cobol, but I'd been doing hobby programming since I was 12, and writing games in c++, so I wasn't typical. I completed a bs in cs at night and moved on.

Agreed. I don't know how it is in other countries, but most currency exchange offices I have seen in Romania use FoxPro software running on an MS-DOS equivalent. I haven't used FoxPro in the last 20 years, but some people still make a living with it.

[Now that I think about it... I have actually written a small program in Visual FoxPro last year to interface with a .NET application... huh.]

This is true, but there are a few caveats.

The one that I've been running up against most recently is that a lot of this new-fangled stuff does not really have a strong value proposition, and I personally do not want to waste time on it.

This has become especially true since "cloud" hit critical mass. Junk seems to get generated 20 times faster than it used to and see much wider adoption. GitHub profiles are now status symbols and everyone feels a need to have a bundle of their own showpieces to display.

A lot of the fads are totally perplexing, from the perspective of an engineer who is more interested in building a robust system than padding his resume. JavaScript on the backend (or, even more horrifying, the desktop)? Single-page app frameworks like Angular for everything, including very simple pages? Why?

Yet, it's hard to find a web-oriented position that isn't asking for a background with some SPA and some Node.js. Maybe it's a fad, but it's still going to impact your job prospects.

The takeaway: stay on top of fads and new tech, even if you resent it and think it's really dumb.

I had the same experience with Rails; I hated so much about it and put off getting serious experience with it for 4 years or so. Turns out I still hate it after years of usage, but it was much easier to find work, both as an employee and a consultant, when I had significant experience in the fad.

Didn't matter that I was learning all kinds of new tech that I thought was interesting. As much as one may hate it, it's usually best to bite the bullet and ride the market's waves.

The most frustrating one today is Kubernetes and Docker. Ansible was so beautiful. I hate Docker with a seething passion (not necessarily other container systems), and I see Kubernetes as a very rough toolkit for people who have Google-scale problems that no one should be trying to make for themselves.

Other caveats:

* sometimes techs DO go extinct. Though COBOL is not quite extinct yet, I've known COBOL coders who have gone years unemployed (that doesn't happen to anyone who knows a language/stack still in wide circulation). A small niche has pros and cons, and one of the cons is that the supply:demand ratio is fickle, and may not always be in your favor.

* It is very rare that your technical qualifications will be so unique that they will take precedence over your personal and political qualifications. This is something most developers try to dance around, but the fact is that tech is ultimately run by people, and they want to be comfortable more than they care about that loop's runtime. If you're looking for something that will confer huge career benefits, the odds are that improving your people skills will be more valuable than improving your technical skills. This is almost universally true. It's especially true if you think it's not.

Most of the application stacks I see that are popular I think of as being invented by people who didn't bother to look around at what had already been tried and rejected by the previous generation.

Caveat I don't build apps that need to scale to millions of users.

But I think you should re-consider Node.js. JavaScript is based on an ECMA-specified (ISO-adopted even) language with at least three major implementations, plus smaller (yet still highly regarded) ones. The Node.js API is (loosely) based on CommonJS which is as good as it gets in terms of a community API standard for JavaScript.

Genuine question. I'm not a fan of it either, after working with it for two years, but I can't quite explain why. Maybe it's the "magic" aspect of it, since so much is convention, DSL, and hidden away.

One of the most prominent examples I remember is developing a form and explicitly setting the form's method in the Rails code, of course precisely according to the documentation because we know how picky it is. However, because of some minor detail in the content of the form (which I unfortunately don't remember specifically), I found that the Rails JavaScript was overriding me and dynamically changing the form's method when the form was submitted. I had to hack in the middle there to subvert that event.

It took forever to track that down, something that should've been so basic and simple. This is exactly the kind of anti-feature that developers resent: it's supposedly there to make things "easy" by assuming you meant something, when you've taken pains to say that you did not in fact mean that because you assume it's going to assume you meant that. When you complain, the Rails community blames you for not believing in magic hard enough.

That's emblematic of the entire Rails experience; it's just one example among many. We all know that any moderately-complex program is going to have unique requirements and want to do things that are a little out of the ordinary; if it didn't, you'd just be using something pre-built like Wordpress.

When you get to that point, you're going to be tearing your hair out and fighting Rails the whole way, as it insists that no, you didn't mean that when you explicitly defined it in the place the docs say to explicitly define it; you clearly meant the thing that Rails says you meant.

It'd be one thing if this type of behavior was acknowledged and respected as a bug, but it's not. The response you get is usually along the lines of "Well, why were you trying to disobey Daddy Rails? You are a very naughty coder. DHH could surely beat you in a street race, and you probably haven't even read REWORK." The Rails community is a cargo cult.

Rails is not to be introspected or customized. It is only to be appreciated and praised. After all, you are not as successful as 37Signals, are you?

And don't you like magic? Are you not entertained? Magic won't work if you change all the stuff. Don't ruin the magic! The great visionary DHH has come down with the visions of what web applications should be. Do not defy him.

They try to cover all of this up by saying that they believe in "convention over configuration". This means that if you question Rails, for any reason, you will be punished for your insolence. They truly despise heretics.

That's not how frameworks are supposed to work! I sometimes don't even like calling Rails a framework because it's so rigid. Frameworks are supposed to give users the tools and flexibility they need and then get out of the way.

If I feel like I'm writing Ruby (or whatever the base language is) and the framework is just helping me get that code onto the web (or provide whatever the framework's function is), then I'm happy. If I feel like I have to write in a special framework-specific dialect, then it's not a framework; it's a platform, and I'm writing a plugin for it.

I think this revulsion from big-magic black box "frameworks" like Rails and CakePHP led to the rise of "microframeworks", or "semi-reasonable ways to put code behind a web site", as normal people call them. ;)

The best ones, then, tend to be the ones that have been around long enough, or had enough foresight to have covered various corner cases.

The other issue is that most of them have "per user / per month" pricing, which doesn't work for many use cases. Things like, for example, an applicant tracking app. If you use the functionality to a high degree, every job applicant is another end user license.

Two of the better ones: http://quickbase.com & http://ragic.com

Other ones I've seen: http://caspio.com, http://knack.com, http://fusio.com, http://trackvia.com/, http://podio.com, https://www.zoho.com/creator/, http://airtable.com, https://getzenbase.com/, http://www.zenginehq.com/

One of the more promising ones was DabbleDB. Twitter acquihired them and shut the tool down. It had a very smooth UI: https://www.youtube.com/watch?v=MCVj5RZOqwY

One I hit in many of the tools was lack of a good UI widget for select fields that have lots of choices. Something like a combobox with autocomplete.

Maybe he sees pedestrian get shot on the street while he walks to his desk and smiles. Maybe a chair screeches on the floor, reminding him of the screams of some kid five years his junior he was beating up in high school. Maybe he cuts his hand on the edge of his giant mahogany desk and the drop of blood fondly makes him remember the thousands of children whose families he sucked dry, and condemned to abject poverty at his previous bank job, reveling in their inescapable fate. We will never know. An epiphany happens.

Then he proceeds to phone up some lead architect and asks the question "don't we fully control the data that these cloud 'customers' think is theirs" ? He likes the answer so much he fires the lead architect on the spot.

And his eyes twinkle.

I've saved countless hours by doing as you suggested - only using the tools that have matured, where all standard questions are already answered on stackoverflow and common corner cases are covered.

So when I see Google App Maker, my response is "cool, this might be something I can use in a year or two, let's see."

https://developers.google.com/appmaker/scripting/overview

Sometimes the wall is the data model, or the construct they give you for navigation, access control, roles, etc.

Something like freeform javascript that executes in the client would help a lot, because you could patch around limitations in many cases.

Smoothing out the transition from on-rails to off was one of the original design goals, so there was arbitrary server and client scripting from pretty early on, and a component model to create widgets. The project as moved from being hosted on App Engine to being hosted on Docs infrastructure, so I'm not sure what the specifics of extensibility are, but I suspect they're pretty good, but more Apps Script oriented. Should be a good solution for heavy Docs users.

My thinking in this space is that you really can have your cake and eat it too with these tools, though it requires a really thought-out design, and that they built-in features use the same extension points that are available to users.

With JavaScript available on the client and server it becomes less of an issue whether you can run code at all, and more of an issue of whether you can run at the right time and intercept the right flows. Especially with Web Components on the client pretty much taking care of components. Providing a standard router on the client and server with similar middleware and handlers, and also middleware/handlers on state changes, you can get close to easy to start with and fully extensible.

The other limiter is less technical. Finding a way to charge per user only for true internal users. That was my other stumbling block...tools that want to charge for everyone that touches a built app in any way whatsoever.

1. App Maker developer wanted to create App Maker Apps .

2. Web developer needed to transition our App Maker App to a javascript / python / ruby standalone project.

And a lot of my best freelance jobs recently have been for companies not traditionally in the tech industry who had a new idea they wanted to pursue, proofed the concept with a Wordpress site, and then once they had some degree of market validation, needed a developer to build it into something more robust and customizable.

We are looking at a number of these rapid development tools. Hopefully google opens it up soon before we select a different one.

I'd be curious if this platform has sticking power. Google rolls these sorts of offerings out from time to time and then shuts them down. If I knew there was a couple years of runway for this offering my fears would go away.

I have no idea if it worked, but at least that way it does something. Per default, the form just doesn’t do anything for me.

App Maker < App Engine < Container Engine < Compute Engine (VMs)

So pick your poison for the business problem at hand. Don't host your blog on a dedicated VM. Don't use App Maker for training neural networks.

The question is really one of execution (and remaining modern). Too generic and it lacks a killer app. Too specific and it hides of a niche.

What I have seen is non-programmers getting enough power to get overconfident only to wind up with a mess.

These type of applications make it super easy to do 85% of the work. Unfortunately the remaining 15% often turns out to be impossible. Additionally when requirements change (and when don't they?) there often isn't the flexibility needed to make the changes.

The last thing I've observed is when something goes wrong if the person can't drill down into the internals and make adjustments they are just plain out of luck. I've seen this with both Access and Lotus Notes. Companies struggle with bugs for years. I've had a fair share of work re-writing these type of applications into web applications which finally do what is really needed without issue and can be changed when required.

In short I'm not concerned. Seen it before. Works for very simple apps, blows up spectacularly when something non-standard is needed. And this makes work for me.

Maybe this time it will be different but I really don't think so.

- speech recognition so that you tell what you want

- LEGO blocks for simple things that can be composed and adjusted by voice or AR gestures

- large amount of working code so that "glue" between blocks can be inferred using ML/DL

I am pretty sure App Maker 2.0 will have at least 1 of these finished.

It's funny 3-4 years ago when I first started to learn web dev, I had a lot of ideas that I thought would be "viral/make money" but now I have hardly any... a lot of my ideas back then were pretty dumb too looking back at it.