I work with business stakeholders creating internal line of business apps a lot, and most of the time the requirements that they are able to articulate are some variation of vague, ill-specified, and flat out wrong. And it's not their fault at all, it's just that unless you've gone through the process of writing code it's impossible to understand just how pedantic and explicit you need to be when building software versus, say, giving your human colleagues instructions.
And by the time you've got enough experience to be able to do that, tools like this just get in the way compared to writing some Python or SQL or C# or what have you.
I'd never tell anyone that learning to code is easy (only that most people can do it with some hard work), but I would also never tell anyone that tools like this will make it easier because I do not believe that to be true.
What you get in low code reality are smart ass business consultants that know magic configuration options and demand loads of money for their work.
Just look at SAP, Salesforce etc. From my point of view any barrier to entry doesn't matter because at some level you just trade one complexity for the other.
For non complex stuff excel works fine and low code is not advertised as alternative to excel.
But here's what I think you give up if you don't have code. Over the past 70 years, one of the problems that computer science has studied is how to manage the size and complexity of programs and development teams. This complexity includes not just the program you're working on, but potentially the entire ecosystem of algorithms and solutions available for your use. Nothing comes close to "code" for addressing this problem.
As a result, I think if you're going to give up code, you have to accept that your projects will run out juice if they get too big or complex, or that you will have to solve some interface problems with manual steps. That might be perfectly OK.
But they should. People aren't stupid, shells aren't horrifically complicated if you try a bit and once you climb that hurdle you're suddenly a "tech genius".
Learning to code is an extremely high barrier to wntry, but its also highly transferable. If you can write Python, there's tons of jobs you can get writing Python, and with a little extra work, you can pretty easily transition to another language with a whole other world of opportunity.
The problem with these "visual" languages, is its a lower barrier to entry, but its still takes a detail oriented person, and ends up being very specialized, so there's less opportunity to leverage that to another job. So if you're a person than can learn a visual language effectively, you might as well go the extra 30% and learn to code in a "real" language.
Low code solutions work by presenting a simplified view of the world to the user. Once your vision doesn't mesh with their abstraction, you end up having to dive under the hood if you're lucky enough to have a solution that lets you. In the best case, you've now had to learn the underlying tech and the abstraction.
1. Understand the problem
2. Break the problem into subproblems. Goto 1 till subroblems
are small enought to be tackled.
3. Develop the algorithms for each of the subroblems you got
after step 2. No handwaving allowed.
4. Implement the algorithms.
Having taught people to code, there's a lot of "perception" about what is hard that you need to overcome, but in practice, people learn that part comparatively easily.
When I made the move from native software (Windows applications w/GUI in .NET) to web applications, I found the transition to be _extremely_ overwhelming.
And for the most part, the frustration came from trying to manage setups and dependencies, and keeping up with the bazillion of packages.
I can absolutely see a beginner getting turned off by the initial process of just setting everything up, before a line of code has been typed out.
I (mainly) work in inventory management and this is so very true. For our specific requirements, there wasn't anything in the SaaS space that would work short of SAP or Oracle, no other vendor had all the requirements in one package.
However, our quality control department had tasked me with writing standard operating procedures (SOPs) for most of our receiving & warehousing processes. I swear, those .docx files took longer to write than the custom inventory solution I ended up coding. However, most of that SOP time was sitting in front of a whiteboard trying to figure out how to explicitly define all the processes in detail. This experience was incredibly valuable though, I'm convinced that having to define the business process beforehand made the software vastly easier to write. I spent more time getting django configured & setup than coding the business logic, and the business logic was complicated enough that I couldn't find an off-the-shelf solution.
I've since done this for some other projects at the same company (I wear a lot of hats), and spending 1/2 a day bothering the 'customer' with my incredibly pedantic questions while we drew up a flowchart or bulleted list saved so much time down the road with catching edge case bugs. Note that I'm not talking about waterfall style dev, this only focuses on the actual business process and not at all on software. There aren't any questions about how the software should function, but instead 'if a customer has this problem, what do we do?' The trouble is, this strategy wouldn't work if you can't force the user to spend quite a bit of time on what is an unpleasant process for everyone.
... then you get into standardised work flow diagrams and you are so far into UML that it just becomes programming again.
If you need that extra 20%, hand the resulting project off to professionals to build an application out of it.
Or the time you spend trying to debug some basic functionality you've written 20 times before because it isn't quite working with everything else for some reason...
'It is impossible to automate this club with 100 membership options and 300 members, it is just too complicated'. I think there is some complex psychology behind statements like this. There are elements of not knowing what is possible, elements of not knowing how to break down a problem, but also an element of not wanting someone from IT to come along and show you that the job you care about and you have to work hard at can be automated away. I tend to approach these things by building rough prototypes of the simplest case, and using that to find the edge cases. All the while using lines like, 'this will allow you to concentrate on the sales part of your job, rather than admin'. But here is the truth, most people want stability in their work life, and are terrified of what systems people might change.
In another sales-order flow project I worked on I was suspicious of the time taken to manually intervene with orders (I was worried it was stopping us from scaling), so I started asking questions like, 'what takes you a long time?', 'what could be improved?'. Apparently nothing, it was all fine. We started to map the process out and began the tedious work of finding out how the manual process works....one day the person was frustrated with one element of their job and let slip about a process that took hours that had apparently slipped their mind previously. This was manna from heaven. I attached two senior developers to the team and they fixed that problem in half a days coding, but it couldn't go live because x needed doing first. I let them do x, and they found y..so it took around three months more to fix this simple flow, I would say there are in the order of 1000 loc generated in total. I agree, it is the human part of these kind of systems that is hard, not the coding.
Many people aren't even going to try to do anything involving code, and it doesn't matter if they could if they tried, because they won't.
Lots gets lost in communicating with a developer.
Creating one of these honey comb things is going to force who is working on it to be precise, in a much better way than talking to a dev (or writing a story). In no small part because one can play and experiment without being intimidated by a dev. It might be buggy but the feedback loop is tight, the creator can see errors and fix them fairly immediately.
The result probably won't be beautiful, but neither is anything I end up producing.
You hire new accountant and what he does just throw away all records and build his own app from scratch?
Someone will create that honeycode thing and then he will be responsible for changes in that application.
In the end you have a maintainer on that app and lots will get lost in communication with him.
On the other hand you might have one off apps that are needed for specific task, but that is what excel is for. Reading about honeycode I see it is not about throwaway one off apps. So there will be someone who is "developer" who has to know details of honeycode and application he maintains and bunch of people with requests who don't bother learning what that honeycode thing is.
Like the parent says, there are absolutely going to be people who will be defeated by Honeycode (or any other solution no matter how easy) because they simply can't or don't develop a model of the domain that an app can serve as an interaction point for.
As you say, there are absolutely going to be people who can do that, with Honeycode or something else, but are put off by the specific arcana of some language/dev environment. Just like there are people who don't think of themselves as developers but do an awful lot of spreadsheet work.
The v1 of each one, which was immediately useful and used, usually took me 4 to 8 hours to create. That includes the time talking to the main user to understand what they needed.
I can't achieve the same speed with Django or Flask. Maybe others who are more experienced developers can?
In my experience, that's a 4 to 8 hour project.
Oh, and runs against a real database.
Just this week I had a lengthy 2 day discussion involving 4 other employees, 8+ long emails, and hundreds of words in chat ... all to figure out that we need to add an if/else statement and two simple lines of code.
The code took 2 minutes. The discovery took 2 days.
The "curse of knowledge" works both ways.
Of course it's not the code itself that is complicated, but what do you want the overall system behavior to be (are there upstream/downstream/breaking effects?) and why. And do you understand the system well enough to know the right way to make the change - sure it only took you 2 minutes to code it but that's because you already understood the system well enough to know the right place to change the behavior.
I've worked with multiple companies who've had some form of no-code products. In every case, incorporating the full gamut of business requirements entails in too much of configuration and complexity in the UI. At this point, there are only two options left for the user -
1. get trained in the software which itself is time consuming and a challenge
2. ask the vendor company to create the app, which kind of defeats the whole purpose
A few other points -
1. People to whom no-code apps are targeted tend to be in the management rather than the actual users of the system. Management is usually aware of the bigger picture or the more complete workflow.
2. However, managements requirements tend to be more around tracking, reporting and monitoring.
3. The last issue being management tends to get caught up too much in the UI rather than the underlying functionality.
Unless no-code services restrict themselves to a very specific niche with clear workflows and fewer options of customizability, the products are bound to be cumbersome, complex and having a very narrow applicability.
Every application in existence is a CRUD app. Software is just data processing after all, reading and writing bits.
After tinkering with this one, areas I see lacking are 1) no authentication 2) no images and 3) limited automation options. I'm sure it's coming in later releases, but just an example. Even tools like AirTable etc. that do have auth are often lacking. For scenarios where you want users to only see "their" data, managers to see their employees' data, and vps/admins to see all data are common scenarios that are often hard to implement in these tools.
I'm watching this space for a breakaway, but haven't seen one that I feel is better than written code. I admit bias as a dev, but I do wonder if written code is not fundamentally superior in most cases. Even "Visual Studio" ceased being visual drag-and-drop for most people ages ago. Sure, you _can_ still drag-and-drop windows forms apps, but most devs will write XAML, or in web space, use a CSS framework and markup instead of a drag-and-drop designer.
This is exactly a major problem I'm solving with https://www.cloudternal.com. I would absolutely love to show it to you and get your feedback on it if you have time (my email is in my profile).
1. Writing and process flow as you describe are incredibly important. But, many developers can’t write. Writing is a fundamental skill that takes practice to develop and many developers do not independently practice that skill, despite its importance.
2. The web is a multi-faceted discipline. This is the hardest part to being a web developer. Learning to write the code is comparatively trivial. This is also the greatest cause for frustration and failure for people and automagical software alike.
3. Precision of requirements is important but not as important as many junior developers would suggest. The discrepancy largely arises because many developers find writing to that detail challenging themselves and are frustrated when feature delivery fails to match stakeholder expectations. QA and PMs seem to regularly nail this issue without challenge indicating its not the requirements that are ultimately at fault when things move out of alignment.
I must say if the tool has a right type of user identified then nothing can beat noCode.
- Updating the server the software's hosted on - Dealing with system errors installing software - Setting up software on your company's webserver (and dealing with firewalls) - Installing necessary plugins which may require installing new software that's not compatible with your version of Linux, etc. - The fact that a lot of web software is designed for a Linux environment and can be completely foreign for someone with a Windows background - Updating the software you're coding on
The difference is that now, you lack the vast and mature test automation ecosystem to help manage that cost, and more importantly, the friction of shipping changes is completely gone.
Requirements gathering becomes an interactive process where you sit together with a business stakeholder to model your application together: by doing it in a visual manner, the stakeholder can understand what you are doing, and you can process suggestions and feedback in seconds, so that the stakeholder can immediately validate the results of a change.
Doesn't work for all requirements, but in many cases you get better software because you understand the requirements better.
(This happened a lot when Visual Basic came out - management types would spend a weekend playing with the visual UI editor and then give the developer a week to fill in the complicated business logic behind it.)
(Developer here who has t-shirts older than a some of the people posting)
Preach! This was something I did not understand when I was only doing non technical product stuff. Now that I build I look back on my interactions with developers differently. I feel their pain so to speak.
I don’t know if builder tools like this thing perhaps create bumpers around the many pitfalls associated with turning analog into digital, but I’d presume eventually they’ll get good enough to act like the automated customer service you get from amazon support chats.
Surely, building apps with such accelerators is limited. You're trading customization power for speed to market, and you get a lower barrier to entry which enables business focused people to build stuff they need.
Those apps aren't for everyone and I don't think any enterprise will be able to live with just these platforms, but enabling users to live without IT has a lot of value.
However, the key here is right abstractions, sometimes seemingly tiny changes are impossible in these no-code solutions due to the abstractions that were chosen.
So no-code tools are actually extremely rigid in comparison to programming languages, but they still have a place and I believe it's still a growing industry.
My joke is that the only place a stakeholder should hold a stake I'd through the heart (on the bad days).
Some stakeholders are brilliant they explain what they want in sufficient detail and get out the way.
The worst are the ones who try to tell you how the software works internally.
You don't hire a builder and then interfere with every brick course laid down, at least if you want the wall finishing on time.
It does make you cloud/product/service independent. From Amazon's (or Mendix', or what every code-without-code product/service) perspective you are not vendor-locked-in enough.
It's progressive improvement. It's trial and error, without this process we'd never ever make progress.
TL;DR I had a tough day on legacy system because learning to write code is easy and learning to write good code is hard. I actually saw this today "SELECT %s FROM %s WHERE %s JOIN %s";
On the other hand, I absolutely loathe every single UI that has ever come out of AWS, and there is absolutely no chance I give the editor they've built here a shot without hearing lots of positive reactions first.
edit: actually going to pull back slightly on this comparison, since apparently Honeycomb is a little closer to something like Access, where there is a database _in_ the app, whereas Retool is built around connecting to an external data source (e.g. a SQL database). This surprised me because I assumed the entire reason you'd want an AWS version of this kind of tool is to integrate with the broader AWS ecosystem, like frictionless hookup to a DynamoDB or whatever. It may have this but just not spotlight it on the marketing pages?
I agree so much with this. I hate the AWS console UI so, so much and It blows my mind that such a large company can't seem to even get on the same page about what color scheme or menu bar position they want to use.
But actually, I'm messing around with Honeycode right now and although I haven't gotten a chance to really dig deep and test the long-term usability of it, I have to say that so far it is gorgeous and intuitive. If the UI team that worked on this just completely took over the AWS console, I wouldn't complain.
I can't even figure out why I hate it so much. Looking at the screenshots though immediately filled me with the sense that this thing would just be awful to use. When I go back to the screenshots to try to find objective things I dislike about the UI, I can't really find anything. It seems to do the stuff a UI needs to do.
Maybe it's just a negative association with the look & feel of AWS UI, because most of the time when I'm interacting with AWS I'm trying to get a service I haven't used before up and running. Going back and forth between dense documentation and the UI, clicking and failing, and staring at a spinner spin for far too long.
Perhaps all those hours spent fighting with other pages that look so similar to this one has given me a subconscious dislike for all AWS UIs.
This is the fundamental misunderstanding. There is a centralized AWS console team/organization. They are responsible for the UI libraries, guidelines, common elements, mezzanine, etc, across all of AWS.
They dont write the actual "service pane" UX that you interact with when you start an EC2 instance or upload an S3 object. That surface area is so large, varied, and changes at a frantic velocity that there's no way a single team or group could ever keep up. Even a single "service" like EC2 or Systems Manager actually has multiple front end teams responsible for different portions of the UX or functionality.
Isn't it the other way around? Being a large company makes coordinating on an uniform look and feel much harder, not easier.
Oh, I love, hate, detest, adore, or any number of other negative and positive adjectives the AWS console UI, all depending on what page I visit.
Microsoft PowerApps with PowerAutomate (formerly Flow, their Zapier/IFTTT) have a huge advantage of being bundled right into other licenses. SalesForce and ServiceNow have similar advantages. Quick Base[1] has to be considered the incumbent. Zoho, Oracle. And then the more independent Appian, Betty Blocks, Mendix, OutSystems.
This tends to be one space where consolidation and acquisitions aren't as popular, and the big players have built their own home grown products on top of their stacks. (counterpoint, Kony got snatched up by a fintech software services company, Temenos. Apple acquired Workflow which isnt quite the same thing but a tangent space.) In a lot of cases, its going to make way more sense to go with the Vendor that already provides other parts of your infrastructure. If you're an Oracle company, Oracle Apex is going to be simpler, which is the point of all these offerings. It makes a ton of sense for AWS to provide this naively on top of their already mature offerings.
It's also not a space I'd want to enter as an independent startup, from scratch, unless you are sure you can actually offer something better and different. Or, instead of a generic offering, your product is tailored to the specific processes and workflows of certain industries. At this point if you want to join this crowd, it would be a safer bet to hitch your ride to a specific tech company lacking this offering (if there is one left) and become so good that they want to acquire you. Or build a specific subfeature in this space, so one of them gobble you up and tack you onto their product (see 3rd link.) I would guess there is still room for some ERPs to be interested in tacking app builders on, like Infor.
https://www.gartner.com/en/documents/3956079/magic-quadrant-...
https://flow.microsoft.com/en-us/blog/microsoft-acquires-sof...
[1] Somewhat shocked to not see Quick Base mentioned even once in this thread. It's a billion dollar company thats been offering this nonstop for 20 years, and is still relevant.
Our bet, however, is that code is here to stay, since code is actually a pretty efficient way of getting a computer to do something [2]. With that said, though, building specific types of apps (in our case, internal front-end apps today) is surprisingly difficult (have you tried recently!? you have to use react, redux, install 10+ npm modules, etc... just to make a front-end that has a table + POSTs back to your internal API!).
And so that's why we're building Retool for engineers, which has resulted in a few interesting decisions:
* we are not a system of record, since engineers don't like to move data around. We'll connect to your data, no matter where it is (e.g. postgres, a custom API, salesforce, etc.).
* we rely on the user knowing how to write code. I think this is interesting because low-code is good for getting to 50%, 60%, etc. But as you try to get closer and closer to 100%, it becomes harder and harder, since full customizability within a GUI (without code) is just hard (cf 2.). Retool lets you get to 60 - 70% of what you want very quickly, but then relies on you finishing the last ~30% with code, if you really want to. (We provide APIs, let you import custom React components, let you write JS anywhere [3] within {{ }}.
this also has led us to embracing git syncing (serializing retool apps as yaml files and syncing them to git repos: https://docs.retool.com/docs/git-syncing ), being on-prem by default (https://docs.retool.com/docs/setup-instructions), etc.
(If anybody is interested in working on this, please email me at david AT retool DOT com. I think there's really a small chance we can really change how business apps are built.)
1. Funnily enough, when we started Retool, there was no low-code / no-code space. If you look at our original Show HN (https://news.ycombinator.com/item?id=17725966), you'll see that nobody mentions "no code", "low code", or anything siilar. It's certainly been fun to watch a "trend" pick up around us, haha.
2. For example, imagine a switch statement. Very simple and concise in most languages, but incredibly hard to implement in a GUI. (A graph with nodes and edges, perhaps?)
3. We secure it by running all JS in a sandboxed iframe.
I bet you're getting a lot of traction on corporations that need to upgrade/replace internal tools.
I know, internal tools will always suck because:
1) your market changes faster than you can change your apps, so you're always lagging behind.
2) And technology moves faster than you can keep them to date. That's the reason we still have IE as corporate browser in most enterprises.
Also, 3) nowadays it's very hard to do both good frontend AND backend coding. Technologies diverged a lot since, say, Rails 2.0 (which is just 8 years away from now). And the barrier to compete is higher every day.
Or just use HTML, CSS, and JavaScript?
Agreed, a seemingly missing feature is how can lambdas or other AWS ecosystem components interact with this data? I could imagine systems where it's nice for "no-code" and "code" to interact cleanly.
I think pretty much all the 'no code' apps that are coming out have taken the wrong approach to it. No matter what, they are still 'designed' by programmers with a programming mentality. This will lead to a sort of failure as people will feel limited when using it, and a 'non programmer' mentality looks at this and goes wtf?
For example:
> =Filter(Tasks,"Tasks[Done]<>% ORDER BY Tasks[Due]","Yes")
I can understand this, 80% of folks here also, but do your mother or father? Or the small business owner down the street? Why is the word `Tasks` in 3 places? What is the "Yes", and so on and on
Anyone who can write working spreadsheet macros could probably just learn to actually program. Maybe they aren't going to be making the next RTX Voice or proving P=NP, but I'll bet they could crank out some CRUD
People that are good at using Excel (as in, not just create a table with data, but know how to use it, do macros, pivots, etc), if the need arrives they just move up the chain to Access/Filemaker. I would say Excel is their gateway drug to coding. Maybe now they will move to Honeycode perhaps (if the UI is ok)
The ones that can't use Excel past putting =A1+A2*0.2 can't use most of the no code tools. But they can use a more visual approach to programming. This is the market I believe will/is exploding as more and more, pretty much everything requires a computer/app, but the customisation for each specific case isn't there. They require a more Lego like approach to 'software' development. For me, that is the NO-CODE definition.
Further, if these things do start taking off I don't think the people using them will be non technical people, it will just be technical people shifting their job description.
It is like an all in one hammer, the craftsman throws it in the garbage, and the non craftsman has no idea what to do with it.
And I'm 100% sure that no company would let them anywhere near that kind of stuff,even if it's vanilla drag and drop. Those people are good at some jobs and task but definitely not at this. Anything designed for purely non technical people usually is just a bit crappy: I taught myself programming so I won't need to deal with Salesforce Flow...
You mean they prefer to call someone for 10 minutes and pay them to build the app? Or a recommendation to use an existing app?
The only saving grace it has is that most of the interface is "no code" so that you can focus your training on smaller pieces... But that's just "low code" at that point, which isn't nearly as marketable.
- If the product ever gets discontinued you might lose all your work.
- All these tools have limits regarding the amount of rows you can store.
- If your business depends on such a product and the pricing model changes, it might bankrupt you.
- You can't create or download real plugin that integrate well if you are missing features.
- In most cases you can't host it at your own servers.
- You might end up in a vendor lock-in.
These are some of the reasons why I started Baserow. It is an open source alternative to Airtable and in the far future also for tools like Bubble. While it is still in an early phase there is a test version at https://baserow.io that everyone can try. In the coming weeks you can expect the open source release. Right now, I am finishing up the documentation, examples, plugin boilerplate and some final small changes. After that you can self host it without any limits, vendor lock-in or price changes.
After about a year I noticed I was basically doing the same thing over and over again, so I decided to make an app that makes web apps! I could build any app in my app! Awesome! I spent 4th year building this awesome tool out - there was a document editor to create your forms, there was a Visio-like flow editor that could make decisions, take actions (email to that person, fill in that field, send to branch 2 if that checkbox was checked etc). After a few months I eagerly applied to YC (for summer 2007) and... nothing. Turns out I couldn't actually describe wtf I was doing and pg would rather fund Heroku. Good call!
Anyway, there were other similar companies back then (Coghead) that went nowhere, but this concept keep on popping up and AirTable seems to have caught on. I guess someone at Amazon got tired of writing the same apps over and over again.
The breathing + pausing at commas/full stops and general cadence was frankly superior to what I've seen with Google Cloud Voice, which is why I was curious if preprocessing was done. I've generally had to do multiple manual passes with Google Cloud Voice to get audio output that didn't sound robotic.
I spent years in my early career doing Lotus Notes Dev, then shutting down all those apps to go to Sharepoint, then shutting all those down to go to Salesforce. I walked away from that churn about a decade ago to just do SaaS, so I can't truly speak to which of the newcomers has the most promise. But I have yet to see someone take on this market with full knowledge of what came before. I see potential for someone to really learn the in and outs of all such products over the last 30+ years, talk to the folks who have re-done their LOB apps in multiple products over that time, figure out what worked and build a true "best-of-breed" solution.
When someone does do that, I'm all in. Until then... the legacy apps I mentioned above are past their time, so pick your favorite flavor from all the new ones.
Except most people want to be consumers of applications, not creators. And those who really want to be creators they learn how to code. So, like with Pipes, I am not really sure who is the target audience here.
Microsoft Popfly[1] was another one from back in the days.
Good try though.
https://hn.algolia.com/?q=without+writing+code is an interesting search
The merging of Cloud + Software consumerism of 15 (ish) years of mobile + software eats world can make the Bubbles, Airtable and other no/low code tools the next long tail revolution of software ?
What is different from the front page + Dreamweaver + flash days ?
My hint : cloud computing and the hosting of database AND logic in bigcorp maintained garden
In fact I think that people who make that claim are wrong. Low code development tools have become hysterically successful, especially in recent years. WordPress (400+ million websites) has 50000+ plugins that can do almost anything. Look at Salesforce (17 billion revenue) and PeopleSoft. Airtable (1.1 billion valuation). Shopify is approaching 1 million sites. Wix has $600 million in revenue. There are a lot of other massively successful products that fit into the loose association you gave.
For example: Access, Salesforce, WordPress, Tableau, 10000 other ones that never became really popular including the simple one I made ten years ago for a client.
https://en.m.wikipedia.org/wiki/Low-code_development_platfor...
https://en.m.wikipedia.org/wiki/Fourth-generation_programmin...
https://en.m.wikipedia.org/wiki/Rapid_application_developmen...
We believe there is still a gap in the "database app for non-technical users" space, so we created one that can handle millions of records, provides granular permissions down to the cell level and targets those creative (yet non-developer) users who end up pushing Excel beyond its usefulness.
FYI: When you try to request early access, I get an SSL error.
Amazon also has the Microsoft—esque brand to really drive this into the Zeitgeist. IMO this might be the most game changing product they have launched recently given how much of a business impact it can have if distributed well. But therein also lies its biggest challenge - Amazon hasn’t historically been good at offering their services to the small businesses and consultants that could leverage this and build for the long tail. I wonder if they have a strategy for that.
I think using this in the real world will be about as easy as trying to buy the right phone charger on Amazon.com. People consistently underestimate how long it takes to learn complicated interfaces. At which point you might as well just learn python.
Take any advanced 3D modeling software for example. They are visual interfaces, not command line tools, but they might as well be considering the learning curve for the average user.
Having visual buttons doesn’t necessarily mean the process of building a 3D model (or a piece of software) is suddenly easy.
We’re quite excited to see the no-code space heat up with Amazon joining the fray.
What would make it better is if:
* It’s open source, therefore installable on-prem and free from vendor lock-in.
* It has multiple swappable backends.
This thing and Bootstrap can replace a myriad of random in-house apps.
For the sake of clarity, couldn't they have come up with a name that didn't include the word "code" ?
People solve problems and build useful tools using Excel, even those who have no realistic expectation of ever learning to write code. In fact it may be the most widespread programming tool.
Are there things it can't do, and problems with scalability and collaborative development? Sure. But BASIC had those problems and nobody says it isn't programming.
I've seen master programmers use Excel, when they wanted to do something with mixed-type tabular data and graphs, that they could share for others to use.
For a lot of people, hacking a spreadsheet together is easier than trying to communicate their needs to a programmer.
Anyway, this is still "programming", of course. You have inputs, you transform them, and you get outputs. What Excel gives is the ability to see all the intermediate calculations update as you stitch things together, which is very different from the software engineer approach (where we think of all the inputs, and write tests to make sure a particular sub-module works, and then treat that as working forever). The software engineering approach lets us build very large systems reliably, but the spreadsheet approach lets you build simple things very quickly.
Yes, for everyone, many times. You just have to carefully define what "programming" is.
Even when there's initially no "programming", soon things like "macros" will be added.
frontpage98 was the one to kickstart my web experience.
They are good to start somewhere from, but they'll never be a replacement.
Maybe more like Filemaker Pro, circa 1990.
edit: But this.. it is polished.
Microsoft is the one that needs to come up with a defensive play here, because this is an area where Excel is used in many businesses both small and large. I'm guessing Microsoft could do a better job than AWS integrating this with Excel and the Office 365 or MS Teams kind of UI to make it feel at home to their users.
On the other hand, AWS is ahead now and likely to start integrating this with the rest of their services if it takes off.
Either way, I think this can be an interesting development for a lot of half baked Excel processes that are everywhere in a typical company.
Those people are not going to be giving up Excel for this. I have tried for years to get people to use other better tools than excel, it is a non-starter
Power Excel Users will not stop using Excel for either PowerApps or this AWS Product
I can foresee Microsoft and other bigger players entering the no code market seriously in the near future (though one can say Microsoft already has power apps etc).
If Amazon Honeycode does not have that critical feature (ability to write code) - then Amazon Honeycode is useless for creating any complex applications.
In other words, Bubble needs more competition.
One hard problem here though, by the looks of it, the tool is a database designed by engineers in response to a lengthy requirements document. It has no regard for user experience, and is one of those things you can use, only if you go through a 3 week training course.
This, imo, is where AWS could borrow from startup playbook, and instead of launching a spaceship, start instead with a paper airplane. Imagine if all you could do was to publish an inventory-management tool, that in one-click integrated with Amazon Pay and let the customers buy your products on a website?
Maybe Amazon is waiting for someone else to build this on top of their tools, and then make it available, but that poses a question why. Why would someone build on top of Honeycode, only to have Amazon eventually make it their own?
Interesting concept, but it's got a long ways to go before anyone needs to be scared of what Amazon can do with this thing.
In fact, the whole "no code" Dreamweaver analogy isn't all that fitting. If they just said "Excel spreadsheet on steroids that integrates with other AWS product," would make more sense, to me at least.
However, if something like Honeycode also had a robust programming/design API, you allow for tons of flexibility.
We could build a lot of it without code, and we could build a lot of it with code, and even better, we could code more things that can be built without code on an app by app basis.
[1] https://press.aboutamazon.com/news-releases/news-release-det...
If your business domain has a feature that doesn't fit then you have a difficult conversation with business people who won't change their process to fit the platform and won't pay to rebuild in a platform that does fit.
If you do manage to customise Honeycomb then you're down a path of not really fitting into their model or having to upgrade on their product roadmap, not yours. I've seen SAP and Sharepoint "installations" that have been customised beyond all recognition.
Where this will fit nicely is for those internal apps where people are just using Excel or Access-like systems.
Using low-code as a developer to iterate faster, and bang out lots of mini code apps quickly, is an interesting idea.
Back in the day there was this cool concept of creating a bunch of UML diagrams for your business logic and them BOOM - press a button and here is your C++ code. But then architecture astronomy hits the asphalt and you realize that most of the hard work is still ahead. So things like IBM Rational Rose were only sold to suckers.
- Lightsail (ie. self-hosted wordpress)
- Cloud9 (IDE in the cloud)
- Workspaces (remote windows/linux desktops)
- Workdocs (cloud documents)
- Workmail (email)
- Chime (audio / video calling)
Definitely not future-proof as new business rules may be hard to add after a while, but by then the PoC has shown its value and ROI, and writing a real app might become a no-brainer anyway.
Of course with AWS resources this can change with time. They did hype this some months back, I was expecting something a bit more impressive OOTB.
They either get Flustered and end up back in Excel, or the "app" gets handed off to IT / Development who get frustrated and start a project to rewrite in a actual programming environment
A spreadsheet to track a project need not be an app, the ability to temporarily give access to internal data to a non developer team (which become CSVs in email) is not an App.
It is this need of building a full solution which actually takes us away from the need of the users to the need to justify a resource for the thing.
Also, this thing requires a different login even though I'm logged in to an AWS account with corporate SSO. Like quicksight and other tools do, and it's just as infuriating. Just let me start using and bill for usage.
From what I've seen many businesses use Excel sheets as a sort of apps. And this seems to be a mobile-compatible version of that idea. Of course it'll be very limited, but for a certain niche of business apps it could be very useful as a replacement for Excel.
i feel like Anvil is on the right, almost perfect, track -- except for their choice of Python over Javascript. They chose self.Python over javascript. ok. life is full of decisions. in their defense, callbackjavascript is...not so promising.
bubble went with..something. right idea. not the best execution. still, a step in the right direction.
saw a couple other tools out there that are trying to cross the chasm, but nothing as good as VB yet.
Or is this just for apps that would otherwise be run from a spreadsheet, and not displacing anything an engineer would build?
Although the world still needs lots of developers I do believe there is a BIG opportunity in the #nocode space.
=Importrange()
In google sheets.
They also have one huge advantage that no-one else besides maybe Google have - integration with Office 365: your corporate directory, email, filestore... Which means they don't even need to be the best at this kind of product. Good enough, plus the integration, is a game changer.
Sharepoint in real life seems to be a very complex product with few people actually knowing it. Out of a company of 10,000 people we probably have 5 guys actually knows anything about sharepoint, Why is it so obscure?
1. Amazon isn't especially known for high quality software. I picture lots of weird corner cases that won't be tested or fixed in their frantic pursuit of new features (which is what's rewarded, like Google if not more so).
2. Sky high Amazon attrition - especially in engineering!* - means that it's always newbies who'll be working on it, under high pressure.
I have trouble imagining a non-trivial corporate app with any kind of lifespan living on this thing.
*I live in Seattle so any Bezbots can save themselves the denial of harsh reality.
I don't see a single innovative idea in this product and I see plenty that's worse than the experience I had in Dreamweaver in year 2000.
I am no fan of Amazon, but I do not think it is as bad as you describe. Even if it is half as good as Airtable, this will take off, simply because of Amazon's weight behind it.