During my first job after university, I spent a bunch of time developing apps using Lotus Notes. Because all of the company's 2000+ employees already used Lotus Notes for email and calendering, deploying these apps was easy.
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.
Hi, I am the guy that came in a few years later and had to reimplement a bunch of custom (undocumented) Lotus Notes applications in order to move actual documents to a proper document management system (with access profiles and searchability) integrating the apps in an intranet portal, allow them to talk with other applications and finally put everything under SSO.
I have also found that when I enter a new workplace, everything done before me was a mess of unwieldy, poorly documented and unstructured code. Worse it uses an old, archaic platform that is long overdue for a complete overhaul.
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.
The easiest scapegoat in software history: the previous developer(s).
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.
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.
I, too, would like to pat myself on the back for having excellent code management skills, and problem solving. But most of all, for going completely meta on people.
The best is when you work on something, then shift to another part of the business, come back, and uncover some crazy construction that has you scratching your head and what the hell the person who made it was on at the time.
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>
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).
You are wrong: the project I described is real but was most assuredly not for the company you worked with (for a start, it was for a big Utilities company... in Italy).
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).
This is a real misconception a lot of programmers have about Lotus Notes shops.
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.
In my experience speed vs. reliability soon transmogrifies in inertia vs. rational (and usually inertia wins).
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.
I find this better than the people who try to build 3-tier sql dB driven apps for all those scenarios.
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.
What lots of people fail to understand is this: little work-saving apps seems to work magically (for the users) because a lot of the logic, especially how to handle thorny edge cases which nobody considered before, is left in the brain of the user himself.
If I designed an app where a particular use case would be handled by "write down the caller's number on a post-it note and then ask George from accounting over a coffee cup at the cafeteria" I would face the firing squad.
But ironically enough this is how the "little spreadsheet my cousin helped me with over the weekend" handles this case, and all other unanticipated cases, and this is great because it's not a 3-tier sql dB driven app. (An app that handles everything else, though, and has to meet also regulatory requirements including SOX).
I’m a software developer. I build big things, and I wrestle through rewrites of spaghetti Code. I once had to convert a start up from a cold fusion web site the ceo and biz dev (both non developers) had written. I get it.
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.
I'm one of the team that was hired to take the Excel app that one overdue-to-retire person had spent 20+ years developing (without documentation, and inserting every miscellaneous feature he felt was desirable, regardless of actual need, and which, of course, he wanted all of to be kept) for the entire company's metrics and reporting, and turn it into something that could actually be understood by anyone else, with proper database normalization, API access, etc.
I'll gladly take your word for this. My company was contracted to do the stuff I described, but the decision came from the customer's IT staff.
Maybe it was political to milk more budget for the project.
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.
>> The moment that they need to scale, they become a liability, like...
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.
Yet Excel is probably one of the best "UIs" you could support for data entry in the workplace.
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".
A problem is that before you have a webapp at the level of Excel without any customization, we're talking developer years of effort. Webapp frameworks are for trivial frontends, they make the equivalent of slide handouts.
(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, Notes/Domino got a bad rap for a lot of stuff, like the cruddy 90s UI that never got updated, but it was quite powerful for what it was.
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.
It seems a little presumptuous to assume every app in any language is not built well.
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.
Tools like that can be extremely productive, and easy for people of no or low programming ability to utilize.
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.
> nobody but the original creator really knows what's going on
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.
A friend of mine spent a very lucrative few years in the late 90s, early 00s doing Excel contracting. Usually for banks who seemed to have quite a lot of these monstrous abominations and a wish to make them far more monstrous going by conversations back then.
Paid for their Porsche 911 until the .com bust broke contracting generally.
>> Tools like that can be extremely productive, and easy for people of no or low programming ability to utilize.
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.
I worked for a huge consulting firm that had built a lot of workflows around Lotus. I hated it at the time, but then I moved to an org using Exchange. I asked how to do something simple like send a five question survey by email, allowing editing, and combining results into a dB and was surprised Exchange didn’t have an equivalent.
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.
If you don't care about confidentiality, then you can do a simple survey using a SharePoint 'List'. It's as easy to set up as a Notes database. But less flexible.
That’s what my IT people said. SharePoint is harder to use, integrates poorly into outlook, lists are a terrible data source, SharePoint permissions are buggy, and the pricing model is all different than outlook.
It’s effectively a whole different platform than exchange and so it’s basically easier to use survey monkey or google forms.
Very similarly was HyperCard. It was a bit before my time, but reading up on it, it seemed so powerful and yet friendly for non-programmers to use to make useful tools.
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)
I always got the impression that Lotus Notes was a great idea, but very poorly implemented. The concepts in it were good, it was just a shame it inflicted so much suffering.
I still wish for a widely-deployed replacement for Notes/Domino.
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.
"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."
IIRC, File Maker Pro Advanced is basically FileMaker Pro with additional features enabled. You would be able to use that in its place, but it might have a higher price tag.
What aspects of Lotus Notes seemed like a good idea? Genuine question. I remember being horrified by almost everything about Lotus Notes. Sametime was great, though.
I realized how great Sametime was after I was forced to move to Skype for Business. The meeting functionality wasn't great but there were other great features. I sorely miss the button that allowed you to drag a rectangle on your screen and it would automatically send the resulting screen capture as a message. Not as an attachment that you had to open up, an actual image in the chat. Why can't skype figure that out!?
I started this as my 20% project many, many years ago. I since moved on to the Dart and now Polymer teams, but I'm very, very happy to see the project launch.
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...
Congratulations on starting a great project!. I've been experimenting with App Maker for an internal Edu project and it looks great. I noticed that Drive Tables are gone; did they not scale well?
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.
After more than two decades in the industry, you start getting cynical towards these kind of "programming for non-programmers" tools. All of them are trying to abstract away the complex parts of the programming problem. Guess what, it doesn't matter how many layers of abstraction you pile up, you never abstract away the need for consistent logic. You end up requiring the same kind of people that have the brain skills to actually program.
I had a lot of the same opinions, and then I actually got a job at a low-code platform vendor.
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.
Yes, I consulted on such a product for a few years, all the people doing the successful projects with it were programmers. The tool was very productive in it's domain.
I did QA for a Pega BPM project at a regulated company, working with an off-site (though on-shore) Pega consulting firm. Aside from the usual big-co version of "agile", and that this was a legacy rewrite, the process was more or less the same as regular C#/Java development.
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.
It's all relative. One can argue that "true" programmers program in Assembly and languages like Python or Javascript are just high-level abstractions over Assembly. SQL is another type of abstraction which was originally intended to be used by business users (hence the English-like syntax) yet developers are happy with it now.
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.
For a good programmer, the language is just a tool to make what you've just thought out. To me, programming isn't about how to code, but about what to code. What makes somebody a good programmer is the thought process before a single character of code is written.
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.
>For a good programmer, the language is just a tool to make what you've just thought out.To me, programming isn't about how to code, but about what to code. What makes somebody a good programmer is the thought process before a single character of code is written.
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.
Programming in assembly isn't harder (in fact quite the opposite), it just takes more grunt work. The actual difficulty of solving a problem (the 'irreducible complexity') is the same regardless of language.
There's a difference between useful, tried and true abstractions like SQL or compiled languages. As you accrue decades of experience, you start to learn that some abstractions are just hopeless, like those tools that sell themselves as "programming for non-programmers" which promess you that you won't need to write code. A new version of this comes up every few years.
>Picking the right tool for the right job will always be a problem to solve
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.
Right, that's why the best abstractions are built on solid tools, and if needed, give you access to that lower level foundation.
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.
You're pointing out that programming languages are relative to the level of abstraction needed but not the quality of the programmer. So true! Programming is programming.
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.
>> All of them are trying to abstract away the complex parts of the programming problem.
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".
But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do.
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.
>> But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do.
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.
I don't necessarily see that as a problem. When you get to that point, you've proved that this task, whatever it is, was worth automating. You've built a tool and even though it was clunky and limited, people found it useful.
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.
> But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do.
> 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.
True, but there are many people who can handle consistent logic but are not familiar with all the technical detail required for general purpose software development.
There is a lot of complexity that is completely unrelated to the core logic of a solution to a particular problem.
I have not experienced this. Every 4GL/5GL/wysiwyg in my decades ended up with some specialized user type learning the syntax of dragging blocks or whatnot.
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.
>I have not experienced this. Every 4GL/5GL/wysiwyg in my decades ended up with some specialized user type learning the syntax of dragging blocks or whatnot.
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.
Yes. At my employer we have evaluated many BI solutions who offer simple tools to develop solutions and really at the end of the day the IT people are going to be the ones doing the work. We have a few power users but investing in an expensive tool for just the dev team to develop in seems to be over doing it.
Is there any of these higher level languages that doesn't add its own accidental complexity? (essential complexity being the one included in the core logic of the solution to the problem).
They usually have their own jargon/terminology and concepts to learn.
No, I don't think it's just moving the goal posts if the difference between learning one or the other tool is measured in years.
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.
But a lot of apps nowadays are essentially just forms to send data to a backend. If those apps can be 'trivially' made then that's a clear win, I'd say?
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?
> a lot of apps nowadays are essentially just forms to send data to a backend
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.
If the needs never change and are 100% addressed by the app maker, fine.
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.
Let me approach this from another angle. Excel, effectively, is 'programming for non-programmers'. And many of the accountants using it don't even realise that what they're doing is programming. So what? It works for them, helps them do their job. Maybe in the future we create neural code interfaces that let us express our code in an abstract symbolic way instead of as a sequence of characters, and we think back on textual code input in a similar way. Obviously the relationship isn't quite the same, but there's definitely a parallel. Some people can write good code and understand it, others can't, same with any platform. So what?
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.
It's a tool for businesses to get a web site presence so they can pay Google money to promote their sites.
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.
We’re basically in agreement, right? Getting App Maker to the point where its bottom line contribution can be shown to exceed $4M/a by 2020 seems like tall hill to climb.
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).
App Maker requires G Suite, which is a paid subscription service ($10/user/month for the "best deal" business tier).
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.
Good point. Does that change the economics model to one closer to Netflix, where the goal of the development costs is to hook more people into the subscription?
The business is simple: helping companies get stuck on Google's cloud, Same as microsoft sharepoint/power-apps(?) and Amazon is also working on such tool.
I don't think a layer of abstraction that hides away the complexities of building apps is a solution to a problem to begin with.
I'm probably wrong and biased by the fact that not only does it take away the fun in engineering products, but also that the target demography is "business."
Perhaps not a solution to complex applications, but for trivial apps what's wrong with hiding a little complexity?
Say, by reducing the complexity of a tool that encourages a programmatic mindset you make it easier for new learners to get started who otherwise may have been scared away.
I'm not quite sure why you have a bias towards business targeted platforms... most things are these days I suppose!
I for one am quite excited about app maker. Finally a CRUD tool that links to just about any data source (including spreadsheets), does not require desktop software, generates properly responsive applications, needs no maintenance or upgrades to be secure and will presumably be compatible with Google forms.
I recently started learning PowerApps due to work and yeah, this seems like Google's "answer" for lack of a better term. I feel like one of the main draws for PA is that it's got a lot of integration with O365 and the rest of the MS suite, but does Google have the same sort of enterprise presence to make this a realistic competitor for market space?
I agree from the standpoint of a user of a service, but that's just how it is nowadays because they work like a giant startup incubator. Several ideas are tried, as many as possible, as fast as possible, and some are worth for them to keep. Most are not. At least if it is opensource, if Google abandons it but it still is useful for a reasonable number of people, one can hope that a community will form and take over development.
Does it matter that App Maker is only available with a G Suite business subscription? I'm skeptical too, but at least this is (indirectly) a paid product.
That's the key point. It's going to be a revenue producer from Day One.
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'm not seeing 24 products in 2018, but just 1 - Encrypted Search.
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)
Just say no. Developers should recognize when a tool no longer fits the problem space and move on. That does not invalidate the other usecases in any way. Not everyone is a developer, not every problem needs to scale.
Unfortunately, yes, this will become hell for some. Job security for others and ..
Having used Access a few times I find it hard to believe how anything could be worse than that anti-productive, database corrupting, File Already in Use piece of garbage. It's astounding that they're still updating it.
If it doesn't lock in data access like MS Access did, it could be seen as just an interface designer. Whatever data it gets fed, could be migrated from a simple database to a proper backend if such need arises. It could even coexist with other front-ends.
As long as it doesn't let too much business logic to be programed into it without a simple way to extract it, it shouldn't be a problem.
The problem isn't that Access locked in data, it was that people stuck with MS JET engine instead of hooking ODBC server properly - then Access became a funky, useful UI tool for databases.
The default datasource is a regular Google SQL server, so if you want to change something later on, just plug the DB credentials into your new thing. There's no lock-in.
Google is a huge company. You might wonder what that has to do with anything, but ... after years of frustration let me just state with absolute certainty:
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.
This is Google. We know it'll be one of two things :
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.
It's what SharePoint is. Except that by the time you've fought through the awful tooling, horrible performance and useless documentation just to do simple things you've forgotten (or no longer care) about what the original problem you were trying to solve was.
This looks much better. Hopefully it's not a Wave-esque Google hobby.
I agree with you entirely. The awful tooling and and useless documentation are exactly why it is trying yet failing.
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.
I've built a production app internally with app maker and it's quite nice, but you do need to know more than the bare basics of SQL/JS to really be effective with it.
I wonder if Google will deliberately feed the App Maker backlog with features that enable building functionalities from apps that are hosted on Google Cloud? That could undercut some of their customers to the benefit of other customers.
Quick Base has been running its no code platform for almost 2 decades and does not tie you to an information or vendor silo - happy to integrate with many cloud and data integrations.
Tired of having the services and products you like deprecated and abandoned? Now you can build your own services on a platform that will end up deprecated and abandoned!
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.