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