8 ms·

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 j

by 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
    - fragmede 6y ago
      The third option is a small army of temps to clean up the data - either incoming or outgoing, in order for the "good enough" code to work acceptably well. Judging from how many of these so-called second-class employees exist in the valley, I'm not convinced that it's actually possible for code to be better than "good enough" - but that doesn't stop me from trying!
- tsp 6y ago
  Writing a first iteration fast with no code is a smart move. You can later on create a second iteration with more traditional languages and tooling like Python.
  - jimnotgym 6y ago
    That is the problem though. I tend to do that in spreadsheets, then move to code. I don't see where this spreadsheet++ helps?
  - joebergeron 6y ago
    I tend to disagree here. The thing that makes writing business software take a long time (using code, to be pedantic), isn't the fact that it's in code -- it's the fact that the requirements are often so fast and complex that there's no way to capture them in the application without taking a good chunk of time. If you want an application that doesn't actually meet your requirements, but at the very least, exists, get a group of competent-enough engineers together and they'll be able to whip you something up pretty quickly, I reckon. About as quickly as non-techincal people would be able to make something of equal usefulness in a non-code tool. 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.
robbyking 6y ago
I don't think they were saying learning to code is easy, per se, just that it's not the only barrier to launching a successful product.
- nickff 6y ago
  Grandparent said "that learning to actually write Python or Java or whatever is not the hard part of being productive in a business context". I think that my response was reasonable, and directly addressed one of their most important points.
Quarrelsome 6y ago
> You sound a lot like the Linux advocates who think everyone should just memorize a bunch of commands, and get used to using shell. 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".
- oblio 6y ago
  People tend to have better things to do, already, in their own domain. Also doing something you don't like rarely yields impressive results, no matter the endeavor.
- pjmlp 6y ago
  Just like some developers should learn that developers are users too, and not all of us enjoy doing the stuff the hard way just because it feels better somehow.
  - shaan7 6y ago
    I hope you don't really believe that people use the terminal because it is "the hard way". That simply isn't true. There are things where the shell makes it _easier_ to do things - the most common being batch operations. There have been attempts to build GUIs around such tasks but they actually take more effort to understand than using the terminal. Just like every tool, the terminal has its place. So do GUIs.
    - pjmlp 6y ago
      Yes I do, my UNIX experience goes all the way back to Xenix and I have used most of the UNIX commercial clones, and also did porting across multiple platforms. 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".
cbdumas 6y ago
I think you're right about perceived barriers to entry, and I certainly didn't say (nor did I mean to imply) that anyone should "just" learn to code. But I think the promise of "apps without code" is a siren song, always ending in frustration. 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.
- chiefalchemist 6y ago
  Two things to add: 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.
  - exclusiv 6y ago
    To add to that - Determining and defining what to build is not magic unless you write simple and elegant code that delivers on-time and on-budget. 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.
    - chiefalchemist 6y ago
      That's true. Until you realize that the accurate execution that was on time and on budget actually built something that didn't actuslly meet the business needs. Then what? 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."
      - exclusiv 6y ago
chii 6y ago
writing a good (english) novel is not just about learning the english language and grammar. But it is required that the novelist understands the english language well, but it's not sufficient - the novelist also needs a good grasp of more abstract concepts and have creativity as well.
fnord77 6y ago
they teach python in business school these days, so I think programming is more accessible than ever.
analog31 6y ago
Indeed, I've observed that while programming seems easy, a large fraction of people find learning to program is utterly prohibitive. This includes many really smart people. And I don't think we understand why. 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.
- calineczka 6y ago
  > one of the problems that computer science has studied is how to manage the size and complexity of programs and development teams 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.
  - dgb23 6y ago
    All that stuff you already read about refactoring, patterns, paradigms, pair programming, documentation, design, architecture, mentoring: it works. Some take these things more seriously than others though.
  - analog31 6y ago
    Well... I have to admit that I'm not a CS'ist, and I just assumed that a lot of the progress has come from CS. 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.
noir_lord 6y ago
I think it's a case of a bit of both.
ozim 6y ago
Point of low code is to get rid of those smart ass developers who know those magic incantations and demand loads of money for their work. 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.
- TheHypnotist 6y ago
  There is nothing "low code" about work in SAP. Any time you need something remotely custom you need to blow the dust off of ABAP and code it yourself. This happens a lot. Salesforce even requires you go write up some Apex when you want to get into heavy customization.
  - ozim 6y ago
    Now take a look at honeycode templates, those look exactly like things that SAP and friends promise you won't have to code. Inventory management and customer tracker, this looks like they try to sell the same things. Even if SAP is not marketing their stuff as low code or even if you have to write a lot of code there.
- 9nGQluzmnq3M 6y ago
  Doing anything nontrivial in SAP and Salesforce also requires coding, only now you're doing it in proprietary scripting environments like ABAP and Apex respectively instead of general languages like Java and Python.
  - binaryblitz 6y ago
    Don't forget SOQL. SF's own special query language.
- datavirtue 6y ago
  Yeah, this. Low code has been around for decades. It just results in greater complexity with an additional reliance on a propietary tool that few people understand at all. Honeycode is just a slightly better Microsoft Access. Good for doing mockups and POCs though.
rimliu 6y ago
There are enough bariers in the earlier steps for those barriers to entry with programming not to matter. 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. I'd say for majority it ends around the step 2. Programming only matters at step 4.
- sharker8 6y ago
  I think you are doing software engineering at step 2 as well (base case and build recursion for example). The reality is, CS skills are useful even in low and no code scenarios.
davewritescode 6y ago
The only thing low-code solutions do is lower perceived barriers, not real ones. A low code solution has done it's job if it got you to sink enough time into it that you're stuck with it. They're great for prototypes and simple tasks. 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.
justanotherc 6y ago
I think he's partially right, and you're also partially right. 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.
cbsmith 6y ago
I think the emphasis here ought to be on "perceived". 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.

by nickff 6y ago

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
  - fragmede 6y ago
    The third option is a small army of temps to clean up the data - either incoming or outgoing, in order for the "good enough" code to work acceptably well. Judging from how many of these so-called second-class employees exist in the valley, I'm not convinced that it's actually possible for code to be better than "good enough" - but that doesn't stop me from trying!
tsp 6y ago
Writing a first iteration fast with no code is a smart move. You can later on create a second iteration with more traditional languages and tooling like Python.
- jimnotgym 6y ago
  That is the problem though. I tend to do that in spreadsheets, then move to code. I don't see where this spreadsheet++ helps?
- joebergeron 6y ago
  I tend to disagree here. The thing that makes writing business software take a long time (using code, to be pedantic), isn't the fact that it's in code -- it's the fact that the requirements are often so fast and complex that there's no way to capture them in the application without taking a good chunk of time. If you want an application that doesn't actually meet your requirements, but at the very least, exists, get a group of competent-enough engineers together and they'll be able to whip you something up pretty quickly, I reckon. About as quickly as non-techincal people would be able to make something of equal usefulness in a non-code tool. 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.

robbyking 6y ago

I don't think they were saying learning to code is easy, per se, just that it's not the only barrier to launching a successful product.

nickff 6y ago
Grandparent said "that learning to actually write Python or Java or whatever is not the hard part of being productive in a business context". I think that my response was reasonable, and directly addressed one of their most important points.

Quarrelsome 6y ago

> You sound a lot like the Linux advocates who think everyone should just memorize a bunch of commands, and get used to using shell. 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".

oblio 6y ago
People tend to have better things to do, already, in their own domain. Also doing something you don't like rarely yields impressive results, no matter the endeavor.
pjmlp 6y ago
Just like some developers should learn that developers are users too, and not all of us enjoy doing the stuff the hard way just because it feels better somehow.
- shaan7 6y ago
  I hope you don't really believe that people use the terminal because it is "the hard way". That simply isn't true. There are things where the shell makes it _easier_ to do things - the most common being batch operations. There have been attempts to build GUIs around such tasks but they actually take more effort to understand than using the terminal. Just like every tool, the terminal has its place. So do GUIs.
  - pjmlp 6y ago
    Yes I do, my UNIX experience goes all the way back to Xenix and I have used most of the UNIX commercial clones, and also did porting across multiple platforms. 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".

cbdumas 6y ago

I think you're right about perceived barriers to entry, and I certainly didn't say (nor did I mean to imply) that anyone should "just" learn to code. But I think the promise of "apps without code" is a siren song, always ending in frustration. 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.

chiefalchemist 6y ago
Two things to add: 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.
- exclusiv 6y ago
  To add to that - Determining and defining what to build is not magic unless you write simple and elegant code that delivers on-time and on-budget. 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.
  - chiefalchemist 6y ago
    That's true. Until you realize that the accurate execution that was on time and on budget actually built something that didn't actuslly meet the business needs. Then what? 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."
    - exclusiv 6y ago

chii 6y ago

writing a good (english) novel is not just about learning the english language and grammar. But it is required that the novelist understands the english language well, but it's not sufficient - the novelist also needs a good grasp of more abstract concepts and have creativity as well.

fnord77 6y ago

they teach python in business school these days, so I think programming is more accessible than ever.

analog31 6y ago

Indeed, I've observed that while programming seems easy, a large fraction of people find learning to program is utterly prohibitive. This includes many really smart people. And I don't think we understand why. 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.

calineczka 6y ago
> one of the problems that computer science has studied is how to manage the size and complexity of programs and development teams 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.
- dgb23 6y ago
  All that stuff you already read about refactoring, patterns, paradigms, pair programming, documentation, design, architecture, mentoring: it works. Some take these things more seriously than others though.
- analog31 6y ago
  Well... I have to admit that I'm not a CS'ist, and I just assumed that a lot of the progress has come from CS. 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.

noir_lord 6y ago

I think it's a case of a bit of both.

ozim 6y ago

Point of low code is to get rid of those smart ass developers who know those magic incantations and demand loads of money for their work. 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.

TheHypnotist 6y ago
There is nothing "low code" about work in SAP. Any time you need something remotely custom you need to blow the dust off of ABAP and code it yourself. This happens a lot. Salesforce even requires you go write up some Apex when you want to get into heavy customization.
- ozim 6y ago
  Now take a look at honeycode templates, those look exactly like things that SAP and friends promise you won't have to code. Inventory management and customer tracker, this looks like they try to sell the same things. Even if SAP is not marketing their stuff as low code or even if you have to write a lot of code there.
9nGQluzmnq3M 6y ago
Doing anything nontrivial in SAP and Salesforce also requires coding, only now you're doing it in proprietary scripting environments like ABAP and Apex respectively instead of general languages like Java and Python.
- binaryblitz 6y ago
  Don't forget SOQL. SF's own special query language.
datavirtue 6y ago
Yeah, this. Low code has been around for decades. It just results in greater complexity with an additional reliance on a propietary tool that few people understand at all. Honeycode is just a slightly better Microsoft Access. Good for doing mockups and POCs though.

rimliu 6y ago

There are enough bariers in the earlier steps for those barriers to entry with programming not to matter. 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. I'd say for majority it ends around the step 2. Programming only matters at step 4.

sharker8 6y ago
I think you are doing software engineering at step 2 as well (base case and build recursion for example). The reality is, CS skills are useful even in low and no code scenarios.

davewritescode 6y ago

The only thing low-code solutions do is lower perceived barriers, not real ones. A low code solution has done it's job if it got you to sink enough time into it that you're stuck with it. They're great for prototypes and simple tasks. 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.

justanotherc 6y ago

I think he's partially right, and you're also partially right. 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.

cbsmith 6y ago

I think the emphasis here ought to be on "perceived". 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.