App Maker, Google’s low-code tool for building business apps, comes out of beta
techcrunch.com
techcrunch.com
And in many cases I was able to develop the basic functionality of a workflow app whilst I was talking with the main user to gather requirements. And, although the platform supported a proper programming language (LotusScript, with almost the same syntax as VB), I was often able to build what I needed with just the GUI tools and a few formulae (roughly equivalent to formulae in Excel).
There are a lot of Lotus Notes haters. I think the majority were put off by the email experience, which is very different from other systems.
But the ease of developing, deploying, updating and using internal-only workflow applications was truly awesome.
I hope App Maker is as easy to set up, for simple use cases at least.
But just like excel, it's a double edged sword, as people "specialize" in it and create monstrous abomination applications way larger than the tool is fit to sustain. It becomes a rat maze of gotchas and obscure tricks, and nobody but the original creator really knows what's going on.
perl devs used to refer to this as job security :)
That’s true of most “serious” codebases too! Writing code that others can understand takes time and expertise (both expensive), and it’s often not worth it for one-off tools.
Paid for their Porsche 911 until the .com bust broke contracting generally.
Absolutely. BUT, in the early days, the value of return for end users is higher than the cost of development and maintenance. If the tool is useful and grows, it's going to flip where the cost of development and maintenance is higher the the return, and some tough decisions need to be made.
1 - Document Store (iirc, CouchDB was inspired by Notes/Domino)
2 - Replication - even past the 90s, it was one of the best tools for disconnected users
3 - Low barrier to application creation (it was about as easy as building something in Filemaker Pro)
4 - Easy publication of applications to the web (this was BEFORE 2000, so kind of a big deal back then)
5 - Administration of servers was pretty easy
6 - LotusScript (similar to vba) let you go much further than the prebuilt formula language (if you were willing to learn it)
Keep in mind, these benefits were available pre-2000, and in that time many were strong competitive advantages.
Hell, I don't even think all laptops had ethernet ports back then either. In a lot of cases, you had to buy PCMCIA cards for that.
Sure, I can build CRUDish apps with Django, but there are simple use-cases that take me a week with Django, that would have been a day with Notes. It's crazy that things are slower for me 20 years later. I'm pretty sure I'm not dumber now.
http://www.filemaker.com/products/filemaker-pro/
"FileMaker Pro is no longer available. It has been replaced by FileMaker Pro Advanced which includes more features to help you develop and deploy custom apps faster and more efficiently."
Thank you for the experience.
I'd like people that create "quick prototypes" and "just a throwaway excel with a few macros" realized that while they are valuably shortening the time to get something usable they are also shortening the time before their thing turns in a sort of albatross tied to the neck of the users.
My estimate is that for every 20 “throwaway Excel,” only one becomes used heavily and required a painful redesign.
Trying to build all these correct from the start is actually inefficient because 1) you don’t know which 20 is right until quite a while in; 2) the idea that better requirements gathering and design is a myth as functionality and use is frequently, in my experience, new based on the spreadsheet and users don’t tell this to the design team; 3) the cost of properly designing all 20 is enormous so trying to pick only the most likely 5 is still expensive and has a decent probability of producing zero useful systems.
So while it sucks to be the engineer cleaning up some yahoo’s hack that got used by the CEO, I’m not sure what the solution is that is best for the enterprise.
It's like convincing lawyers that they're not needed in situation X. Doesn't work.
But I think there are lots of little scripts and one-offs I write that are suitable for me, but would make so sense as a large designed system. Every once in a while they’ll get promoted or reused.
The solution to this problem isn’t premature optimization to write all my code with max generalization using on the enterprise approved development platform. But to just accept in life there are positive inefficiencies.
There’s also a decentralization argument here somewhere.
The point I wanted to raise is that excel, DBIII+/Clipper, VB, Access and other "low code" solutions are fine as long they help a single individual (or, at best, a small team like 2-3 people max) to be more efficient.
The moment that they need to scale, they become a liability, like... having to add .csv import to your application because the users do all their planning/what-if scenarios on some excel sheet prepared by someone who already have left the company and then they prefer to upload the results (bypassing any of your carefully designed server-side business logic) instead of retyping each value manually.
Damn easy to create new forms, actually not that bad to implement import if the forms aren't brain damaged, it probably beats whatever you make in terms of UX for data entry not to mention ability to massage data locally.
The problem is, IMO, the lack of middle ground. A lot of those solutions are old, and integration of more modern functionality is lagging - it's there, but it's not well integrated because the concept of multi-user system with access controls wasn't a concern when the system was originally made!
Specifically, I would really be happy if people that launch themselves into this kind of little projects could (maybe with help from IT) decide "ok, we have reached a point of complexity where this stuff has really to be integrated back in the main system".
(And budget appropriately for this to happen).
(so "budget appropriately" means developer years for simple apps with equivalent functionality to basic excel sheets. It is not reasonable to expect this to happen)
In 2009 or so everybody decided that webapps don't even need a data table component at all, and I have yet to find such a component that has the features of Delphi 1.0's datagrid (sorting by row, dynamic rows, built in search, accessible, ...)
GWT is the only thing that even came close, even made an attempt (and tolerable means, the third iteration - cell tables). It's the only thing that I ever found tolerable for developing business web apps.
This means that anything built after that point that has a web UI has subpar data presentation to a windows 3.1 app. And it shows. Handling nontrivial amounts of data in a webapp ... well compare Google Sheets with Excel, and it's obvious even there. Sadly Google Sheets probably has hundreds of developer-years in it at least, maybe thousands, and that's what it requires to get a webapp to that point.
Yeah, but this is true of just about any home-grown solution, whether they are "low code" or not. There are surely a lot of VB and PHP ("high code"?) applications that were quickly thrown together to solve what was at the beginning a small problem.
The reason they're not best practices is usually because there's no IT support or money to build it, so someone (often self-learned) finds a way to build it themselves. You can complain about having to rewrite it once it became a mission-critical app, but more often than not, that app would have never been written by a seasoned developer because the original user(s) of the tool couldn't justify the resources to build it at the time.
A couple of things in particular were really good - reliable replication (which meant your workers could work offline and sync back later) and the document based store.
Fast forward 20 years from Domino 3, and you'll notice that the document based store model is still around in the form of CouchDB (spiritual successor to Domino?) and other products like MongoDB.
1. The applications I created were undocumented. They weren't.
2. The applications I wrote were used for managing documents. They weren't (with one exception, which was for publishing process manuals on the intranet, to save trees and improved searchability. That app had no functionality except for the Lotus Notes built-in storage/retrieval/search, and each record had 3 fields: title, reference, content).
I just wanted to explain what happens to all the effort-saving nice little apps that people wrote to solve a real problem in the workplace... and I wasn't picking up on you specifically, I am sure you did your best and that using the tool at the time made perfect sense.
It's just that the real problem (IMHO) has never been "wow with Lotus Notes or whatever I am really productive even if I am not a full fledged developer" - the real problem is who takes responsability for it and how much of a struggle it will be to move the functionality back to a properly intgrated application.
(So apologies, it was just a rethorical trick on my part).
I also worked in a Lotus Notes shop for several years. We built apps on Notes/Domino and did some pretty cool stuff pre-dot-com, including a Project Management system like Basecamp[1] that was a hosted SAAS (using Domino's web server) in 1998 (crazy to think that was 20 years ago), when SAAS was just a buzzword.
IIRC, more than half of our company's Notes development staff were comp sci grads. It wasn't just a bunch of random dudes throwing a bunch of forms together using the built-in formula language.
[1] https://books.google.ca/books?id=jlIEAAAAMBAJ&pg=PA52&lpg=PA...
Then when I arrive, I make everything logical, nice, structured and proper.
After I leave, once again the place falls prey to disorganized minds who take my work and mess it up for flashy new technologies that are not as reliable as what I had done.
For some reason, this keeps happening.
edit: corrected word thanks to @brlewis
Otherwise perfect. :-D
Not to mention self-documenting.
However I've seen it for real too: a former boss calling me about a problem with a Sybase Adaptive Server Anywhere problem. So I tell him I've forgotten it all but it is all documented in the wiki I set up with the guy who supported the system after me so, just search for Sybase.
Well... Turns out that documentation is gone.
The same dev(s) that allowed the place to run with all the long hours and the most check-ins, are the cause of all the woes when the next dev(s) take over (usually to justify a version 2).
The second easiest scapegoat: third parties, component builders and providers.
All of these can be attributed to Not invented here (NIH) syndrome. [1]
Devs always know more about a system they themselves worked on, and noone wants to be liable for a system that they didn't build that can have hidden gotchas simply because it was NIH.
At every iteration in every single system, even outside of software (you can see this in generations and politics), each iteration teaches lessons and uncovers unknown problems or creates them. Many times this is no fault of the creators but the simple iteration attempt progressed knowledge enough to be able to learn about a new problem that could not be found without said iteration/advancement. In this sense iterations and different teams aren't bad, but they will always blame the former because it uncovered new problems, which is ultimately a gift to solutions and progression.
New problems create new solutions which are what we call progression and innovation, and the next in line should be happy those problems were found that they can solve, for they themselves will eventually be providing this service to those after them.
And as you wind your way through the lack of documentation or sanity in how things were done, you inevitably find some sign that the person who created it was...you. <facepalm>
A mess can be made in any language, by every developer, if we're improving every day, looking back, our work looking back 5 years will always look and often feel like garbage.
The Exchange people pointed me to the SharePoint people who explained this is an entirely different license and then showed me how to do my survey. It took more development time and somehow had an even worse UI than Lotus.
So there is stuff worse than Lotus, and I think that enterprises do need some simple way for non-devs to make modules or apps or whatnot that they can integrate into workflows. Basically like Access was in the early days where normies would make databases for paper stuff.
The idea that a non-dev should hire people for simple data collection and analysis, while nice philosophically to me as a dev, is pretty crazy in the long run as it doesn’t scale.
It’s effectively a whole different platform than exchange and so it’s basically easier to use survey monkey or google forms.
But hopefully this gets better with office365.
For a demonstration of HyperCard's power, play the original Myst some time. The original Myst runs on HyperCard (the Mac versions anyway; it obviously had to be ported for Windows and other releases). Incredible.
I struggle to think of tools like these that exist today. Access, perhaps? (and of course the tool in the article)
App Maker has been a huge force multiplier internally at Google. Hundreds of smaller internal apps, many catering to very specific business and HR tasks were created by non-engineers, often times by the owners of the process themselves. This self-determinism in custom software - not having to find and convince engineers to build something for you - is really important as software becomes critical to the long tail of business processes that have still been powered by paper, spreadsheets, emails, chat, etc...
Drive Tables is a feature that came and went since I left the team, so I'm not sure.
I did a bunch of FileMaker consulting before getting my CS degree and joining Google, so a lot of the ideas are based on that type of tool, but thinking of how to do it better: Client and server side scripting with real JS, multiple nested data-contexts per page, multiple data backends, etc.
There is a lot of complexity that is completely unrelated to the core logic of a solution to a particular problem.
They usually have their own jargon/terminology and concepts to learn.
So they just move the goal posts...
But I think it depends on what sorts of problems and solutions we're talking about. I don't believe for a second that all types of software can be created with this sort of end-user oriented wysiwyg + expressions tool.
I’ve seen lots of demos (and bought lots) of reporting or automation tools intended for the “CEO” to make their own ad how reports only to have that mean that consultants are hired or someone else do it.
At the end of the day, the hard part for many people is the idea of variables and abstraction and interfaces and looping and operators. Making a button vs a keyword to do this is maybe easier, but it doesn’t really Bridge very well to non-programmers.
The closest I’ve seen is Excel with people who will not try R or Python but can write lots of stuff in Excel functions and pivots and maybe macros.
There have always been power user types in small and large organisations who are not developers but can create simple solutions, mostly using point and click with some expressions, macros or SQL added in. The ones I have personally met have used dBase, Excel or Access (one of them a non-tech CEO).
Of course they had to learn how to do it. But it didn't take them years to learn nor is keeping the skills fresh a full-time commitment.
I think this is largely a disagreement over definitions. Can something that doesn't involve writing loops and mutating variables be called "building business apps"? I would say yes, but I understand how reasonable people could disagree on that.
It will certainly not replace a lot of complex applications, but if you just want a quick "order a mouse at the internal servicedesk" app then what's the harm?
In my experience that never happens, though, and you either have an incredibly painful process trying to work around the limitations of the app maker, or you end up with a rewrite anyway.
That was true 30 years ago, when VB was popular, too. Heck, that was true 50 years ago, when CICS was popular. "Forms to send data to a backend" is deceptively complex.
There is a need for wide variety of programming tools, ranging from very low-level to very high-level. Any of them is a trade-off in terms of flexibility / cost of development. Picking the right tool for the right job will always be a problem to solve, but having more tools to choose from would never hurt.
Someone who assembles an Ikea cabinet isn't necessarily a master furniture maker (altough they could be!). If all you need is a cheap, cookie cutter coffee table it'll not only do, but it'll be the fastest and cheapest option. However, if you're looking for a bespoke cabinet with dovetails, you're going to need a furniture maker.
I tend to agree with it but there is a bit of idealization here. How to code does matter. It helps to not care about RAM barriers, CPU registers, memory pointers, etc. The span of human attention is only so much broad. Constantly dealing with low-level details obstructs seeing a bigger picture. Assembly coders don't think much in terms of type classes or lazy evaluation.
bigato, on the other hand, is pointing out that the brains are relative, i.e. regardless of the programming language, you still need a programmer's brain using it to be successful.
My experience has been that this is a very challenging problem. Business leaders consistently apply pressure for faster results (rightly so!) which means that technology leaders will also be under pressure to deliver faster results.
Tools at the highest level of abstraction (like the various "declarative programming" app builders) trade away power and flexibility in return for simplicity. The sales teams that sell these tools then inevitably highlight the speed and gloss over the trade off that's being made. The message that buyers (business and tech execs) hear is that a tool can solve problems faster.
That is often true when the tool is being applied to a problem for which it's suited and can be disastrously incorrect when it's applied to a problem it's not suited to.
My experience is that the promise of "faster" often drowns out the voices warning that a tool is being applied to the wrong kind of problem.
If I can do 95% of my work using the super simple UI, and then for that last 5%, I can go in and hack my way with some code, I'm much happier than having to write 100% of the code with code.
Of course, if that last 5% is impossible to achieve at all, then yes, you're definitely not going to be happy and that 95% will have been a total waste.
The biggest thing I learned, the secret truth, is that "low-code" is intended to be a force multiplier for "real programmers". Low-code dev shops look exactly like every "real" shop I've seen: source control, sprints, Jira, "omg feature creep" meetings, insane stakeholders, the works.
"low-code" developers are "real" software developers. They are developing software that is intended to be used at scale by real people to perform a business task that produces value. This stuff is deployed at "real" companies. I'd wager any sum you're using products and services every day that are connected to one of these platforms. (I'm talking, are you an American who goes to the doctor, goes to any national retail chain, buys products and services from large online vendors, etc)
It's a complicated and weird industry but it's been incredibly eye-opening.
Most vertical market solutions were started by advanced end users trying to solve their own day-to-day problems. Chances are they couldn't afford to hire a team of developers to build them a custom solution, so they cobbled one together themselves. Other people in their field see what they're doing, get excited, and a lightbulb goes off - "I can make a business out of this!".
Eventually it gets to the point where those solutions need to start following the rigors of a proper dev shop, but in the early days, it's more often than not the "low code" dev that you're talking about.
Funny thing with Pega is once you break out of the normal BPM-style flow, you'll write almost as much code as an all-code platform, just cookie-cuttered into form fields.
You're right, but you're also looking at it from the lens of a programmer.
From a user's perspective, they have a problem to solve, and they just want a tool that will help them. From their perspective, they are not thinking about it like a programming problem. Even if they have to write a little bit of script/code, they don't necessarily perceive what they're doing as programming.
That's why Filemaker Pro, Hypercard, Excel, Notes, etc. developed huge popularity among "advanced end users".
And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool.
But with programming, it's possible to execute scripts, make system calls, write to files, and initiate network connections to talk to APIs and invoke other 'tools' to continue the task at hand. The tool is now a shape-shifting collection of code that can take on many challenges, limited only by the creativity of the developer. You can't do that with a WYSIWYG, it would be too complex to allow all these functions, so the next best thing is allowing plugins, at which point the tool now requires programming knowledge anyway.
Once again, this depends on the lens you view it with.
With any solution that does a good job, it will eventually grow. Sometimes it outgrows what it was already built upon.
I see this is as a good problem to have, because it's a validation that the problem was real, and that the solution has value. You can also now justify putting some resources against it.
If your starting point is "this problem needs to be solved with programming" and A) you don't have that skill, B) you don't have the money to hire a person to do it, C) your organization isn't willing to give you a skilled internal resource to build it, what are your options?
You can either do nothing and live with the problem indefinitely, or you can try to do something that doesn't involve "real programming" to make your life a little easier.
So maybe now with that proof that a small investment paid off, it is time to take it to the next level and make a larger investment to do it better with professional grade tools this time.
Yes, you have to start over, but if the other alternative was never being able to get to that point in the first place, it's still better overall.
> And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool.
Is this not the problem with any programming language? It's turing-complete, yet you find something you can't do (I mean, brainfuck is turing-complete, but try implementing a closure in it), you complain to the maintainers, they say it doesn't fit the design criteria. Sure, you might be more likely to fit those limits earlier in a visual code design tool, but that's not a fundamental design limitation, just an implementation one.
Google dabbles in these tools, but the business case isn't really there. If anything Web Designer should have been more likely to succeed because it had a direct application — designing rich ads — that would benefit Google's primary moneymaker.
If it makes money, they will keep it. Think about it, Google is paying $300-$400k per engineer, if they have 10 people working on this that's $3-$4 mil per year plus the cost of infrastructure. If the experiment doesn't pan out after a few years, they will kill it.
It's strange to me that HN is a crowd that embraces the idea of "experiment often and toss it if it doesn't work" but then is shocked when Google does the same.
Oh wait...
In large organizations, things are never that simple. There are about a hundred other factors that go into deciding whether a project or initiative is maintained or abandoned. Lawsuits, corporate politics, changing company direction, acquisitions and sell-offs... things rarely come down to "we're making a profit on this so let's keep it alive."
Then there's also opportunity cost. Let's say the project has a 200% profit margin: total revenue is two times total cost. That still doesn't mean it won't be abandoned, because someone might decide that those resources can be better spent on another project that has a 300% profit margin.
Basically what I'm saying is, don't count on App Maker to be a long-term project. There is literally no way to know, but lots of reasons to suspect it will be abandoned (based on Google's track record alone).
It's designed to make internal tools, read the freaking description.
By the way, "read the freeking description" is against HN guidelines and a little unnecessary.
Probably they're hoping to grow their G Suite subscription base by offering some more value added services like App Maker.
It's not a bad idea. Build your apps quickly and simply using App Maker, and you are then dependent on G Suite.
However I do agree that Google has a disappointing track record when it comes to end-of-life-ing interesting products like Web Designer.
It's hard to make a business case these days that we should adopt a particular tool that magically builds web sites or marries Java to web, or other such experiments, when it might be orphaned 2-3 years from now. Even if the Goog keeps it on life support, you don't want to be using a platform that has been abandoned by a critical mass of devs -- fewer resources out there to support it, answer questions etc.
We'll take a wait-and-see stance on this one.
What's the migration path look like for App Maker if you want to leave G Suite?
The question is, how long will G Suite itself last (as a paid service)? If AMZN or MSFT come out with equivalent services for free or very cheap, GOOG may reciprocate, and bang, no more revenue.
I just realized you're counting the Others section and incorrectly lumping them into 2018.
It would seem you also neglected to read Wikipedia's banner above the Other section that stated:
This section is missing information about the discontinuation date of each product in this section. Please expand the section to include this information. Further details may exist on the talk page. (October 2013)
And Microsoft has abandoned over 220+ products and services.
Did they implement the JDBC p̶r̶o̶t̶o̶c̶o̶l̶ API in JavaScript?!
EDIT: Apparently they did exactly that, https://developers.google.com/apps-script/reference/jdbc/
Unfortunately, yes, this will become hell for some. Job security for others and ..
With VERY few exceptions (like, say, the build system or some backend infrastructure) EVERY Google project has essentially it's own private structure, base libraries, framework and things that look extremely close ... aren't really. Also, even components of the same app don't use the same framework throughout. It wouldn't surprise me if it wasn't just the case that Docs and Sheets aren't written in the same language but that the drawings you can embed in both are implemented in yet another language.
1) it'll be convoluted like you wouldn't believe, and enforce an entire nonsensical 20-tier architecture on you. It'll be forced on everyone for decades and grow and grow and grow, with 20 different versions deployed which all support and/or require seemingly random combinations of those 20 tiers (ie. android)
2) It'll be great, fantastic, simple and work ! Oh, and it'll be canceled before sundown.
And of course there will be absolutely no-one who ever answers a single question about it, ever.
In computing we are constantly re-inventing things we threw away..
This looks much better. Hopefully it's not a Wave-esque Google hobby.
The whole thing feels like some kind of amateur hobbyist bit of software where people have kinda-sorta implemented a feature, then got bored and wandered off.
Sadly this requires a GSuite accounts, so it is hard to try out.
I pity the engineers in advance, whose job will be rewriting the horrendous "enterprise apps" this tool will leave behind at the end of its life.
Time is a flat circle.