14 ms·

I think the thing that "coding without code" fundamentally misses is that learning to actually write Python or Java or whatever is not the hard part of being pr

I think the thing that "coding without code" fundamentally misses is that learning to actually write Python or Java or whatever is not the hard part of being productive in a business context. The hard part of creating useful software is that you have to understand a business process and its requirements so precisely that you can write it down for the computer to do. 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.

ako 6y ago
That is exactly what some of the low-code tools aim to address: by having a visual, highly productive tool, you enable better collaboration with business stakeholders. 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.
- sciprojguy 6y ago
  This is all great until you get to the stakeholder who prototypes something in Excel (or Honeycode, I guess) and since it only "took them a few days to do this" can't understanding why scaling it up takes six months or a year and won't listen to you when you try to explain that they under-spec'd the system by an order of magnitude. (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)
unicornfinder 6y ago
Indeed. The hardest part of my job isn't writing code. It's in understanding the problems and working out how to solve them.
- dahfizz 6y ago
  That's because you already know how to code. For someone with no programming experience, the programming would be the hard part.
nickff 6y ago
I think you are radically underestimating the perceived barriers to entry with programming. You sound a lot like the Linux advocates who think everyone should just memorize a bunch of commands, and get used to using shell. This type of insider view is often referred to as 'the curse of knowledge'.
- grumple 6y ago
  Perceived barriers are just that though. This doesn’t remove them - someone still has to learn this system, and you’ve got to pay them to work on it. With a system like this, you’ll quickly come to the cases that business people love to create anyway: you can’t do X with Honeycode but you need to make it happen anyway. And then you’ll wish you’d just done the whole thing in Python.
  - majormajor 6y ago
    > you’ll quickly come to the cases that business people love to create anyway: you can’t do X with Honeycode but you need to make it happen anyway. And then you’ll wish you’d just done the whole thing in Python. 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.
    - LoSboccacc 6y ago
      it's very hard for a business process to do with "good enough" code. in many situation either the output is complete and correct or it's of marginal utility. 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
coliveira 6y ago
I agree that coding is the easy part. But exactly because of that it shouldn't get into the way. I really think that is useful to have tools to generate simple apps without coding. Who wants to create the thousandth CRUD app? It is nice to have a tool capable of create apps from simple logic and reserve programming for when it's needed.
- nightski 6y ago
  At the end of the day you have to translate requirements into software. Whether that is through a GUI or textual. Textual just happens to be an extremely effective method to do so. Every application in existence is a CRUD app. Software is just data processing after all, reading and writing bits.
  - coliveira 6y ago
    I think it is extremely egotistical to think that your way is the only way to do things. If some people are not good enough with text files, then by all means we should provide tools so they can help create simple apps without traditional programming skills.
lubujackson 6y ago
That's the theory, but don't forget the time you spend upgrading Python because some dependency needs it, but some other part isn't compatible with the new version so you spend an hour on Google trying to sort that out. 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...
- mehrdadn 6y ago
  Is there even a way to update Python on Windows? I haven't figured out any way other than duplicate installs, a bunch of manual copy/paste/extract of older packages, and hoping for the best.
  - OOPMan 6y ago
    WSL(2) and pyenv? ;-)
- sipos 6y ago
  That is true, but, equally, you are underestimating the time you spend trying toi do something that your no-code framework can't do, and the extra cost of working with it.
TrackerFF 6y ago
I guess it depends on what you're writing for. 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.
heavyset_go 6y ago
Tools like this are great for getting 80% of the way there, which is often enough in some contexts. I look at these tools like I look at spreadsheets: you can stick a surprising amount of business logic in them, and while the thought of using them might make developers shudder, they get the job done. If you need that extra 20%, hand the resulting project off to professionals to build an application out of it.
sktrdie 6y ago
Great insight. Since the process of creating software must be pedantic, then it seems we must push towards ways of sharing the burden with as many people as possible, and not just ones that can understand the "computer way". And I agree with you that a new-shiny-tool is not pushing towards this direction.
jimnotgym 6y ago
I can't agree enough with what you wrote, but I can add some colour. '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.
tylerjwilk00 6y ago
I agree with this. 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.
- opportune 6y ago
  I frequently implement such features. 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.
austincheney 6y ago
Your comment underscores a few misconceptions with corporate software. 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.
Icathian 6y ago
This perfectly articulates my experience. If everything was as simple as the resulting python code they'd never need me.
rahimnathwani 6y ago
~20 years ago, I spent a year or so mostly creating and updating Lotus Notes 'apps' for internal use at my employer. Most of these were CRUD apps to support existing business processes. 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?
- raihansaputra 6y ago
  That's interesting. Personally, learning Django to be comfortable with it takes quite some time for me. Translating the business process to code means you have to be comfortable with the framework, no matter what you're using. What do you often you feel you're stuck on?
  - rahimnathwani 6y ago
    It's not that I get stuck. It's just that, with Lotus Notes: - 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.
    - raihansaputra 6y ago
      Yeah, that's definitely a good fit. I think most companies would be much improved if they can find someone to help with those kinds of apps day to day instead of having to outsource a shiny app that gets unmaintained or takes too long to develop.
- 6y ago
dayvid 6y ago
The main advantage of "coding without code" that I could see is not dealing with the server and software configuration issues that come up when you code. This can range anywhere from: - 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
- iamEAP 6y ago
  Although you shed some of this type of maintenance overhead, you are still taking on the burden of maintaining business logic. 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.
proc0 6y ago
Yes, precisely this. It seems abstracting applications at that high level will inevitably bake in the business process which is very different for each business unless the application isn't interesting or complex enough. I'm sure within a specific domain, a tool like this can be made (it's usually too costly), but at an abstract level to build any application is missing the real challenge that enterprise software has.
zitterbewegung 6y ago
I think a lot of these low code environments are trying to capture people when they prototype software using Microsoft Excel. The thing is if your stakeholder can also make the product it will save you a very large amount of money and then you could hire someone to port it to Python.
patrickthebold 6y ago
I'm pretty skeptical of your assertions, here's why I think this will be big: 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.
- wwweston 6y ago
  You're both on to something. 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.
- ozim 6y ago
  There always will be a developer, it might be some business person instead of dev but that will be an owner of some app. You don't want to create new application each time. Most of applications are there to be maintained. 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.
bredren 6y ago
> 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 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.
thunderbong 6y ago
I totally agree. 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.
devonkim 6y ago
I think “no code” systems like these are mostly of value for people that want to produce some demo / prototype apps that they can then use to pitch around and then get resources for programmers to flesh out better. If said person cannot come up with such an app without involving a programmer, I’m afraid that the person is not knowledgeable enough in the target domain’s technical details to be giving guidance to a programmer.
- theturtletalks 6y ago
  No-code actually pushed me to learn how to code. I started building an app using Bubble.is and although it worked, it wasn't polished. Learning to build an app on Bubble gave me the confidence that I could actually learn to code. No code is a great segue for early tinkerers into Python or JS.
systematical 6y ago
I mean, writing code that is good enough to easily work with is actually pretty hard. I've yet to come into an organization where I am like "damn, that is some pretty good legacy code yall have there." I can't even look at my old code and say that, certainly not my earlier work. Mind you, I'm not even saying great code. Nothing about design patterns, unit tests etc... just good enough to not be complete fucking spaghetti with 3,000 line classes and 500 line long methods that take you down the rabbit hole. 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";
gitgud 6y ago
well, I think that's understating the value of a no-code tool like this. By having the right abstractions, apps are easily changeable (in a GUI), which means anyone in the business can make changes to the application. 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.
zrobotics 6y ago
>>the requirements ... 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. 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.
- serverQuestion 6y ago
  I think its good to realize that the waterfall method really encourages this. Thinking through everything before building can really help formalise informal workflows. ... then you get into standardised work flow diagrams and you are so far into UML that it just becomes programming again.
cies 6y ago
> the thing that "coding without code" fundamentally misses is that learning to actually write Python or Java or whatever is not the hard part 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.
noir_lord 6y ago
Sounds like we have a similar career track. 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.
conjectures 6y ago
Actually, I think this has the potential to increase empathy between pure-business folks and coders. After having a crack and encountering the inevitable bumps in the road, more people will realize writing software isn't just about knowing some funny syntax.
deleted 6y ago
[deleted]
switch11 6y ago
this is such a beautiful comment. So very true
shireboy 6y ago
I feel like this is pretty spot on to my experience with these tools. I've tried lots of these tools, and been in place to have to recommend them to customers looking for workflow and forms tools "so our business analysts can build things". Inevitably, the developers end up having to use the tool and feeling hamstrung by it. 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.
- thomasrognon 6y ago
  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. This is exactly a major problem I'm solving with https://www.cloudternal.com 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).
kinj28 6y ago
I agree. I am a NoCode fan. I run a small operations of a few million dollars and to run it in Systemic way I built a lot of systems with NoCode as i didn’t have the luxury of putting engineers on the job. While I am an engineer myself, my day job was to run the ship and which meant I had little time available to make systems. 1st google spreadsheet is where I started and quickly made apps for recording attendance and crm and other stuff. Soon I hit a wall and had to have engineers deployed. However since last year I started using a NoCode tool to build all internal apps and today I and my HR manager have put up a fully functional system right from attendance, pms, timesheets, project management, crm , sales , purchase and everything you can imagine as a fully usable web and mobile app. I must say if the tool has a right type of user identified then nothing can beat noCode.
- cultofmetatron 6y ago
  what tools do you use to set all that up? I'm bootstrapping my own startup and most of my brain is occupied for a few critical areas and would love to be able to better ration my "coding mental energy"
HeavyStorm 6y ago
This comment spawned a whole thread that completely fails to acknowledge that there are successful no-code and low code platforms. In fact, Honeycode isn't novel, it's just Amazon's response to Microsoft PowerApps. 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.
wuwuno 6y ago
As a technologist I'm surprised that you need this processed explained to you. It's progressive improvement. It's trial and error, without this process we'd never ever make progress.

ako 6y ago

That is exactly what some of the low-code tools aim to address: by having a visual, highly productive tool, you enable better collaboration with business stakeholders. 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.

sciprojguy 6y ago
This is all great until you get to the stakeholder who prototypes something in Excel (or Honeycode, I guess) and since it only "took them a few days to do this" can't understanding why scaling it up takes six months or a year and won't listen to you when you try to explain that they under-spec'd the system by an order of magnitude. (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)

unicornfinder 6y ago

Indeed. The hardest part of my job isn't writing code. It's in understanding the problems and working out how to solve them.

dahfizz 6y ago
That's because you already know how to code. For someone with no programming experience, the programming would be the hard part.

nickff 6y ago

I think you are radically underestimating the perceived barriers to entry with programming. You sound a lot like the Linux advocates who think everyone should just memorize a bunch of commands, and get used to using shell. This type of insider view is often referred to as 'the curse of knowledge'.

grumple 6y ago
Perceived barriers are just that though. This doesn’t remove them - someone still has to learn this system, and you’ve got to pay them to work on it. With a system like this, you’ll quickly come to the cases that business people love to create anyway: you can’t do X with Honeycode but you need to make it happen anyway. And then you’ll wish you’d just done the whole thing in Python.
- majormajor 6y ago
  > you’ll quickly come to the cases that business people love to create anyway: you can’t do X with Honeycode but you need to make it happen anyway. And then you’ll wish you’d just done the whole thing in Python. 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.
  - LoSboccacc 6y ago
    it's very hard for a business process to do with "good enough" code. in many situation either the output is complete and correct or it's of marginal utility. 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

coliveira 6y ago

I agree that coding is the easy part. But exactly because of that it shouldn't get into the way. I really think that is useful to have tools to generate simple apps without coding. Who wants to create the thousandth CRUD app? It is nice to have a tool capable of create apps from simple logic and reserve programming for when it's needed.

nightski 6y ago
At the end of the day you have to translate requirements into software. Whether that is through a GUI or textual. Textual just happens to be an extremely effective method to do so. Every application in existence is a CRUD app. Software is just data processing after all, reading and writing bits.
- coliveira 6y ago
  I think it is extremely egotistical to think that your way is the only way to do things. If some people are not good enough with text files, then by all means we should provide tools so they can help create simple apps without traditional programming skills.

lubujackson 6y ago

That's the theory, but don't forget the time you spend upgrading Python because some dependency needs it, but some other part isn't compatible with the new version so you spend an hour on Google trying to sort that out. 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...

mehrdadn 6y ago
Is there even a way to update Python on Windows? I haven't figured out any way other than duplicate installs, a bunch of manual copy/paste/extract of older packages, and hoping for the best.
- OOPMan 6y ago
  WSL(2) and pyenv? ;-)
sipos 6y ago
That is true, but, equally, you are underestimating the time you spend trying toi do something that your no-code framework can't do, and the extra cost of working with it.

TrackerFF 6y ago

I guess it depends on what you're writing for. 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.

heavyset_go 6y ago

Tools like this are great for getting 80% of the way there, which is often enough in some contexts. I look at these tools like I look at spreadsheets: you can stick a surprising amount of business logic in them, and while the thought of using them might make developers shudder, they get the job done. If you need that extra 20%, hand the resulting project off to professionals to build an application out of it.

sktrdie 6y ago

Great insight. Since the process of creating software must be pedantic, then it seems we must push towards ways of sharing the burden with as many people as possible, and not just ones that can understand the "computer way". And I agree with you that a new-shiny-tool is not pushing towards this direction.

jimnotgym 6y ago

I can't agree enough with what you wrote, but I can add some colour. '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.

tylerjwilk00 6y ago

I agree with this. 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.

opportune 6y ago
I frequently implement such features. 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.

austincheney 6y ago

Your comment underscores a few misconceptions with corporate software. 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.

Icathian 6y ago

This perfectly articulates my experience. If everything was as simple as the resulting python code they'd never need me.

rahimnathwani 6y ago

~20 years ago, I spent a year or so mostly creating and updating Lotus Notes 'apps' for internal use at my employer. Most of these were CRUD apps to support existing business processes. 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?

raihansaputra 6y ago
That's interesting. Personally, learning Django to be comfortable with it takes quite some time for me. Translating the business process to code means you have to be comfortable with the framework, no matter what you're using. What do you often you feel you're stuck on?
- rahimnathwani 6y ago
  It's not that I get stuck. It's just that, with Lotus Notes: - 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.
  - raihansaputra 6y ago
    Yeah, that's definitely a good fit. I think most companies would be much improved if they can find someone to help with those kinds of apps day to day instead of having to outsource a shiny app that gets unmaintained or takes too long to develop.
6y ago

dayvid 6y ago

The main advantage of "coding without code" that I could see is not dealing with the server and software configuration issues that come up when you code. This can range anywhere from: - 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

iamEAP 6y ago
Although you shed some of this type of maintenance overhead, you are still taking on the burden of maintaining business logic. 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.

proc0 6y ago

Yes, precisely this. It seems abstracting applications at that high level will inevitably bake in the business process which is very different for each business unless the application isn't interesting or complex enough. I'm sure within a specific domain, a tool like this can be made (it's usually too costly), but at an abstract level to build any application is missing the real challenge that enterprise software has.

zitterbewegung 6y ago

I think a lot of these low code environments are trying to capture people when they prototype software using Microsoft Excel. The thing is if your stakeholder can also make the product it will save you a very large amount of money and then you could hire someone to port it to Python.

patrickthebold 6y ago

I'm pretty skeptical of your assertions, here's why I think this will be big: 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.

wwweston 6y ago
You're both on to something. 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.
ozim 6y ago
There always will be a developer, it might be some business person instead of dev but that will be an owner of some app. You don't want to create new application each time. Most of applications are there to be maintained. 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.

bredren 6y ago

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

thunderbong 6y ago

I totally agree. 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.

devonkim 6y ago

I think “no code” systems like these are mostly of value for people that want to produce some demo / prototype apps that they can then use to pitch around and then get resources for programmers to flesh out better. If said person cannot come up with such an app without involving a programmer, I’m afraid that the person is not knowledgeable enough in the target domain’s technical details to be giving guidance to a programmer.

theturtletalks 6y ago
No-code actually pushed me to learn how to code. I started building an app using Bubble.is and although it worked, it wasn't polished. Learning to build an app on Bubble gave me the confidence that I could actually learn to code. No code is a great segue for early tinkerers into Python or JS.

systematical 6y ago

I mean, writing code that is good enough to easily work with is actually pretty hard. I've yet to come into an organization where I am like "damn, that is some pretty good legacy code yall have there." I can't even look at my old code and say that, certainly not my earlier work. Mind you, I'm not even saying great code. Nothing about design patterns, unit tests etc... just good enough to not be complete fucking spaghetti with 3,000 line classes and 500 line long methods that take you down the rabbit hole. 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";

gitgud 6y ago

well, I think that's understating the value of a no-code tool like this. By having the right abstractions, apps are easily changeable (in a GUI), which means anyone in the business can make changes to the application. 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.

zrobotics 6y ago

>>the requirements ... 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. 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.

serverQuestion 6y ago
I think its good to realize that the waterfall method really encourages this. Thinking through everything before building can really help formalise informal workflows. ... then you get into standardised work flow diagrams and you are so far into UML that it just becomes programming again.

cies 6y ago

> the thing that "coding without code" fundamentally misses is that learning to actually write Python or Java or whatever is not the hard part 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.

noir_lord 6y ago

Sounds like we have a similar career track. 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.

conjectures 6y ago

Actually, I think this has the potential to increase empathy between pure-business folks and coders. After having a crack and encountering the inevitable bumps in the road, more people will realize writing software isn't just about knowing some funny syntax.

deleted 6y ago

[deleted]

switch11 6y ago

this is such a beautiful comment. So very true

shireboy 6y ago

I feel like this is pretty spot on to my experience with these tools. I've tried lots of these tools, and been in place to have to recommend them to customers looking for workflow and forms tools "so our business analysts can build things". Inevitably, the developers end up having to use the tool and feeling hamstrung by it. 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.

thomasrognon 6y ago
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. This is exactly a major problem I'm solving with https://www.cloudternal.com 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).

kinj28 6y ago

I agree. I am a NoCode fan. I run a small operations of a few million dollars and to run it in Systemic way I built a lot of systems with NoCode as i didn’t have the luxury of putting engineers on the job. While I am an engineer myself, my day job was to run the ship and which meant I had little time available to make systems. 1st google spreadsheet is where I started and quickly made apps for recording attendance and crm and other stuff. Soon I hit a wall and had to have engineers deployed. However since last year I started using a NoCode tool to build all internal apps and today I and my HR manager have put up a fully functional system right from attendance, pms, timesheets, project management, crm , sales , purchase and everything you can imagine as a fully usable web and mobile app. I must say if the tool has a right type of user identified then nothing can beat noCode.

cultofmetatron 6y ago
what tools do you use to set all that up? I'm bootstrapping my own startup and most of my brain is occupied for a few critical areas and would love to be able to better ration my "coding mental energy"

HeavyStorm 6y ago

This comment spawned a whole thread that completely fails to acknowledge that there are successful no-code and low code platforms. In fact, Honeycode isn't novel, it's just Amazon's response to Microsoft PowerApps. 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.

wuwuno 6y ago

As a technologist I'm surprised that you need this processed explained to you. It's progressive improvement. It's trial and error, without this process we'd never ever make progress.