4 ms·

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 sys

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.

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.