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.

Making an app like this and putting it online (with roughly the same level of features) requires:

* Learning a backend language, like Python * Learning how to design a data model * Learning how to design an admin interface * Managing authentication, security, and performance * Learning HTML, CSS, and Javascript * Learning how to set up a uwsgi server * Learning how to set up an nginx server * Learning how to set up an AWS VM and deploy the above to it * Learning how to use a VCS

I'm an experienced programmer and sysadmin who has done all of those things and more over the last 20 years, and I still can't imagine going to the trouble of actually doing all of that if I can just log into HoneyComb and make everything nice and quick and just get it done.

There's value in learning how to do it, but there's also value in spending your time somewhere else. If you're making a simple CRUD app, bashing it together with Django and deploying it to an EC2 VM is almost definitely not your differentiated value proposition. If it's just a throwaway app to handle some mundane task, then it's definitely not wort hthe time it takes to make it if you don't have to.

That sounds all nice and good until one inevitably runs into limitations of the software. And then it has to be made again, this time from scratch.

> bashing it together with Django and deploying it to an EC2 VM is almost definitely not your differentiated value proposition

It never -was- the value proposition. Customers simply do not care about what stack you used in the first place. They will care when features don't get rolled out because of limitations. Or when bugs arise because developers duct-taped solutions together because of the limitations of their software-making software. Not that traditional apps are perfect, but that's one issue they don't have.

Yes, it is complicated, and if you're making a toy app it probably will suffice. But I would never rely on it for a business.

You sir have options. Every place I have ever worked has at least one app that someone hacked together through some combination of PDFs, Excel and Access. This is a tremendous opportunity for those folks. The ones who will never learn to code, never learn to deploy an application and never get enough visibility to have a developer assigned to their project.

For the everyteam, these types of tools are exceptional. I continue to be amazed by what dedicated people pull-off with these no-code solutions.

VBA, SQL, etc, which is probably what these apps are written with, are code though.

Honeycode is a language of it's own too, it's just a trade off between flexibility/power and learning curve.

I fail to see how Honeycode outright disqualifies for everything related to vast field of "business" because of its limitations. In fact, I think that is very much, where it will be able to solve a lot of problems efficiently.

All of them? No, just like any other tool. They all come with their set of drawbacks.

Sounds to me like something like Honeycode is exactly what is needed then, as a replacement for Excel in a business context. It is yet to be seen of course whether or not they can achieve this, or just replace one unwieldy mess for another.

Disclaimer: Which is why I am working on https://stitchiq.com/

I've been positively suprised that Microsoft seems to have started to finally improve this situation with things like XLOOKUP and increasing Python support in Excel.

Disclaimer: I've published in a group doing research on Spreadsheet improvements, this is the professor's publication history [2]

[1] http://www.eusprig.org/horror-stories.htm [2] https://www.felienne.com/publications

Thanks for the link to your publication, will give it a read.

Spreadsheets are a great tool that allows people to leverage computers without knowing how to code, but they can easily get awful to debug. Even excluding stuff like VBA; which is code, but gets included via google-driven copy/paste development.

For example, excel formulas from other sheets can modify cells in the existing sheet. This modification can be logically driven from changes in a 3rd sheet. So cell 1 in sheet A gets modified for some reason when something changes in sheet C. Formulas in sheet B are changing these values, but good luck figuring out that. Breakpoints aren't really an excel thing, debugging complicated sheets is very hard. Unfortunately, most of these sorts of files aren't available online, as they are viewed as the 'secret sauce' for the businesses using them.

Your landing page is too few on details, so maybe you have solved this problem, but from your comment it seems that you haven't had to approach it from this angle. Trust me, businesses run critical decisions on excel sheets with creation dates in the early 2000's, and the amount of tweaking can turn them into behemoths. That is why the low/no-code solutions scare me- easy to start doesn't mean that you won't have an unsolvable hairball in 5 years.

I have yet to hit the issues per se, but what I am partially betting on, is that once spreadsheets are just an interface rather than datastore (where possible), some of those issues can be resolved. One will loose realtime reactivity, but what they were trying to achieve anyway was to access a "canonical" data point.

I should have a video and more details on the website in a day or two

I'd be interested in discussing this more tomorrow, my email is my hn username @gmail if you want to hit me up when you have more details to share.

That's what this tool looks like will accomplish. A new class of apps will be built - that have never been built before. The so called app market will expand.

This doesn't replace the current apps, or the current set of engineers developing these apps. This grows the overall market to be 10x larger than what it is now.

1) Agreed. Writing the code is the easy part. Determining and defining what to build? That's the magic.

2) In the wrong hands, making things too easy can be detrimental. First, there's add too much, simply because you can. For instance, WordPress n00bs are notorious for adding too many plugins. Why? Because they can.

The second reason is, changing too soon without enough data, without enough user input. Yes, iteration is helpdul. But if it's borderline pivoting then that's likely to end badly. Again, in the wrong hands.

Javascript, java and python have made it too easy to write software. Would be better to return back to the days when everything was written in C and Assembly.

/s

I'm not knocking Honeycode and similar. I think they're great. But they are simply tools. They are at their best when they are paired with a user with some understanding and sufficient knowledge.

You can have all the magic in the world upfront with planning and have it fail spectacularly without the right execution that is accurate, on-time and on-budget.

Yes. Execution matters. But it's only as good as understanding the target. Miss that target (read: meet biz needs) and no one will say "Yeah. But it was great execution."

Although if you're in start-ups, they plan and then build terrible products all the time so the attention to upfront planning and the business needs is way more important in that realm.

Every few years someone comes along with a new toy that promises to finally deliver.

It's been going since at least the 90s (when I was old enough to start reading programming magazines (remember those?))

Truly, software development is sisyphean in nature...

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.

If we can agree on the above, then presumably it's conceivable that the same abstraction principle applies with low code solutions--yes, low code users will know their tool well and earn loads of money, but they will probably move faster than traditional programmers for this domain.

In my mind, this only holds as long as these low-code tools are really more abstract and not just a visual/graphical programming language (I'm sure there are very low-level visual programming tools that would allow you to manage your own memory, etc). It also depends on the domain being amenable to abstraction--if you have to drop out of the tool with some regularity to do things the tool doesn't support (e.g., performance, custom analytics, etc), there's a threshold at which the overhead of calling into a lower level language exceeds the benefits of the tool. I don't know where this threshold is, largely because the domain isn't well defined.

But I do think low code solutions are conceivable for certain domains. I would make the argument that Microsoft Access and Excel either qualify as "low code" solutions or they are at least proto-low-code solutions, and they both deliver tremendous value. I would perhaps even say that Access/Excel are to client-side applications what these new low-code solutions are to web applications. Not a perfect analogy, but I think there's something insightful in there.

Salesforce even requires you go write up some Apex when you want to get into heavy customization.

If doing the first versions in this thing meant you got to that position 6 months earlier than you would've otherwise, you shouldn't wish you'd just done it in Python from the start - your business would be missing even the functionality it has now for another six months.

You will, though, need to get creative and figure out the fastest way to get something close enough to X to make them happy in the tool, or with a hybrid tool+adhoc script approach, etc, though.

So there's still a lot of benefits there to knowing the fundamentals.

it is also geared heavily toward internal software, so it has a very narrow scope, it's not really for startup, it's not really for large enterprise with their it deps, it's not really for jim in accounting with his excel honed trough year of hard work...

it will find a niche for sure, but the harder part of the use case it covers is modeling workflow interdependencies and that complexity doesn't lie in the software

If you have access to only engineers, why would they learn this new non-code tool? If you want an application that meets a very sparse, loose set of requirements, just get them to create it using their normal tools -- it won't take relatively long.

If you have access to both engineers and business folk, there's no reason to have the businesspeople write such a requirement-lax application using a non-code tool, since if all you really want is an MVP that doesn't really meet your requirements, get the engineers to do it -- I'm sure they'd be happy with the freedom to throw requirements out the window. And then when you want to expand on it and flesh out those requirements, the engineers don't have to port the whole thing over from whatever proprietary non-code tool the businesspeople could have used.

If you only have access to nontechnical people, you're kind of screwed. Sure, you can have business-savvy folks whip up an MVP using one of these tools, but then when you want to expand on it, what do you do? You need technical people somewhere in the pipeline to make this work. If you didn't have access to engineers in the first place, this is the juncture at which you could hire some to port the application, but is the technical debt you've introduced worth it?

I don't know -- tools like these seem to target aspirational nontechnical people who don't have the foresight to think two steps ahead.

A MVP is quite often exactly what these people need to get the bosses engineers working on the right product. And often it's not enough and the business folk end up using Excel for 20 years with a string of failed products coming out of engineering.

As a programmer, I'm very lucky, but none more than here. I have access to an infinite amount of programmer time. Okay, realistically that's bounded by the number of productive hours in my life, and more realistically, my level of interest in a thing. But it's easy for me to tell someone else "oh yeah, just get a programmer to do it" - because if I had those same desires, that programmer is me.

But looking at the job market for programmers and the salaries commensurate with the demand for them (both in and out of the Valley), "access to a programmer" is something that many people still have to reach to get, and "learning to code" is not a quick or easy process. Honeycode isn't the first product in this space, nor will it be the last.

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.

Did we though? Can you point out some books, or PHDs or whatever slightly more scientific and substantial than blog-post anecdotes?

I honestly believe as an industry we completely don't know how to scale development and I would love to read something that helps understanding this challenge.

But I'm just thinking of something like the transition from BASIC to Pascal (which I experienced in 1983). There were rules of thumb that we learned in BASIC (avoid global variables and GOTO's) that were formalized in Pascal, and Pascal also let you create much more elaborate named structures, and control the scope of names more precisely.

That's just one really simplistic example, but it rather profoundly improved my programming. On the other hand, I can believe that scaling is still a struggle -- there is still a point where we run out of juice, but it's a lot further than you'd get with BASIC, or with Excel-sans-macros.

Some take these things more seriously than others though.

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".

Also doing something you don't like rarely yields impressive results, no matter the endeavor.

Just like every tool, the terminal has its place. So do GUIs.

Using the batch operations example -- if you know shell scripting, you can save yourself time doing things manually -- but you need to have already traded in the time to learn Shell scripting.

GUIs allow you to reduce time spent learning a domain specific skill at the expense of overall efficiency.

Whatever the UNIX shell provides, can be more comfortably over an interactive graphical REPL, which even allows for proper graphical debugging tools when pipelines don't work as they are supposed to be.

Secondly, since UI/UX has always been one of my focus, I have seen too many throw away CLI tools that don't respect the users of the tool, because "hey they are developers as well, they can fix it, deal with its issues".

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?

- authentication was already taken care of

- adding a field at a particular place was one step (rather than updating a model, updating a view and running a database migration)

- I could make small changes in production (ok, maybe that's not so good!!)

- adding events between different Lotus Notes apps on the same server was a snap

- the learning curve to become productive was just a few days

Of course, I'm not saying every type of app fits this model. Or even that every app that fits this model can be strung together with Lotus Notes functions and without using 'proper' code (Lotus Notes had its own variant of Visual Basic).

But for many use cases, you could do a lot in a very short time without very few lines of code.

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.

AWS is like the hardware store. Who thinks Home Depot is elegant? It's not. Who think their organization scheme is a thing of beauty? It's clunky and just functional.

But the idea is, when you go to Home Depot, you're there to get work done. The interior communicates that. The real work comes after you leave - Home Depot understands it's just a facilitator.

AWS did that.

I personally give credit to AWS for looking at Google, and learning. They could've had some high-handed PM come in and roar ITS TIME TO HAVE A UNIFIED DESIGN SCHEME and then forced everyone to deal with UI updates nonstop, you know the game of 'where did it go now,' 'oh, they moved it here.'

AWS went in the opposite direction. At the risk of ugliness, they give you the most bare bones UI, basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results. We know the downside: it can be unpleasant. But the upside is, it rarely changes, its consistent, and (aesthetic concerns aside) it gets the job done.

It seems a little weird to commend AWS for their design sense, but when you phrase it as their design goals, I vastly prefer them to Google or any other 'opinionated' service.

I could not care less about the aesthetics of their dashboard, when I'm on it I'm there to get something done and I never seem to have an issue with that.

Oh, and then you find that search only supports either exact matches, or (for some reason) suffix matches.

> the most bare bones UI

The AWS UI is one of the most cluttered, complex, complete-opposite of "bare bones" of almost any web app I can think of, except for maybe Salesforce.

>basically 'nudging' you as little as possible - a clean mapping of fields, to pages, to results.

My largest gripe with AWS is that it does not have a clean mapping of fields/pages/results. The flow of getting to "results" in one AWS service is completely different from the flow of getting to "results" in another. The launch wizard for ECS, for example, doesn't even follow the same paradigm that the launch wizard for EC2 follows. One of them has a clear vertical layout with successive config pages, while the other has a mixed vertical/horizontal layout with sub-pages.

When doing something as basic as launching an EC2 instance, the AMI selection page has "Select" buttons next to each AMI on the right side of the page, and clicking one takes you directly to the next page. And then on that very next page, the instance type selection, the format has changed. Now the way you select something is by clicking a radio button (which is on the complete opposite left side of the page!) and then clicking "Next" at the bottom of the page. Why do these two pages require completely different models of interaction when they are essentially accomplishing the same thing?

Even within the VPC service for example, some pages have clusters of information that are right-aligned on the page, while others put the same information at the bottom of the page. Some pages have the "Create new resource" button on the top left, while others have them on the right side. I could keep going... It's the total opposite of "clear mapping of results" to me, and certainly isn't anything close to "consistent".

I don't think AWS "nudges you as little as possible", I think AWS nudges you a lot, but nudges you in completely different directions for every single service, causing you to feel bounced around like you're in a mosh pit when you're having to switch between EC2, CloudTrail, S3, etc.

Even in Home Depot they at least have uniformity in how they arrange their aisles. The nail aisle has little buckets where nails are arranged by a specific ordering system, typically by type of nail and size. If you go an aisle over to plumbing, the pipe joints are all arranged in similar little containers, also with a sensible ordering system typically by type of pipe and size. If you go to the paint aisle, the displays are different but you can still expect them to be arranged in a sensible ordering system, such as by type of paint and color.

If they went the AWS way, the aisle of nails would just be 2-3 large tubs with a bunch of individual nails thrown in, while the plumbing aisle would have things organized in small tubs alphabetically by the name of the manufacturer, while the paint aisle would be condensed like a newspaper with the pages in order of Bob's favorite colors. It would be chaos.

Sorry for the rant. I respect that you apparently like the UI, but it's weird to me that we have such opposite experiences. You say "Home Depot understands it's just a faclitator" and that AWS is too, and I totally agree. But my opinion is that AWS completely fails at effectively facilitating.

That API-first doctrine is at the heart of the underlying problems, which are:

1. Machine-friendly data models.

2. Distributed-friendly data models.

3. Deliberately independent and orthogonal services.

4. A vast range of customer needs over a console that doesn't itself make money.

AWS really does put effort into making their console useful for getting work done. You'll find some workflows that are pretty usable.

But when you get outside a handful of extremely common workflows that were technically convenient for a specific team to implement, those problems become dominant and the console becomes painful if not f*ing useless.

That's why (I suspect) you hate it.

> ... and staring at a spinner spin for far too long.

Oh yeah, fundamental cloud problem #5: "A few minutes" is absolutely forever when you're troubleshooting.

> staring at a spinner spin for far too long.

You probably didn't hate it the first or second time you opened it up. Only after recognizing that many operations are extremely sluggish did you start to build an aversion.

I think the same this can be said about JIRA and many other sluggish, enterprise-y tools. The UI design is typically more-or-less OK, it's the experience of clicking on things and having no idea when it will be done, why it's taking so long, or what a faster alternative is that makes you feel trapped.

I think you might have hit the main issue on the head though, unless you use a service regularly it's difficult to do much without the hefty manuals and while the services may be complex they could make the common or "beginner" paths more obvious.

Having sane defaults where possible and splitting basic and advanced settings could make it more accessible while allowing users to get familiar with the tools. Ideally a good UX should cater to a variety of proficienies and help users learn.

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.

This goes for other aspects of AWS as well, such as consistency in the way services report to CloudTrail or are referenced in CloudFormation. Overall there just seems to be little coordination amongst AWS teams, and that's always surprised me.

This helps with iteration speed and not getting bogged down in middle management approval hell, but it does lead to inconsistency problems.

Apple can do it because all of their legacy architecture and organisational structure was put in place before the internet

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://imgur.com/kD5hQ46

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.

[0] Personally identifying information

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?

Those are good building blocks but they're simply not sufficient if you are building a 'Web App' and not a 'Website'.

Also I'll cut off the inevitable, "The web was not built for this and it shouldn't become a place for apps." The world disagrees, I disagree and most people developing on the web disagree.

And I'll raise that we should be moving more towards the web being the best universal distribution platform for software.

Why treat internal 'customers' any differently than forward facing ones? Building great internal tools can dramatically improve your teams' workflows and solve meaningful business problems.

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.

Now give the same designer Sketch/Figma, but allow him to sprinkle some logic in ready made blocks (if/elses, loops, save object, etc) and he will get much closer to what he wanted.

Is the second approach better? Well most programmers will scream at the database model, etc. For the designer, he did in 2-3 days what would take him weeks and get away with something better.

I think a lot of programmers look at their experience and think 'no-code' will never work, but (where my experience comes) 20+ years of doing software development as a consultant, what I found is 80-90% of most software share most of their functionality, and the remaining percent are in many ways doable with just a bit of 'scripting'

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.

Why build an app if Excel+Email works?

Of course it does.There are people on YouTube making houses with swimming pools by carving soil with some primitive tools but does that mean it's the best way to go?

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.

[1] - https://en.wikipedia.org/wiki/Microsoft_Popfly

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.

Microsoft clearly has a branding / marketing problem, where people have ignored them for too long, and or are just reconsidering products Microsoft has had on the market for 10 year (another thread where people said Office on the web has caught up to gdocs, whereas id say theyve been ahead of it for at least 4 years.)

Mirosoft Lists (their Airtable) is a new interface over SharePoint lists. SharePoint lists are one of the data sources for the Power Platform, but so is Dynamics CRM, ERP etc.

https://powerplatform.microsoft.com/

This issue is that gdocs and co are free while even for just web word you need a subscription. so the only ppl who use it are ppl willing to pay, the freeloaders only see it when their company decides to switch back to MS apps after being in googleville for a few years.

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).

They don't push it as an "app builder" though, more of a web based access that is heavily tied to office/teams.

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.