4 ms·

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.

by tsp 6y ago

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.
- nmcfarl 6y ago
  It has been my experience over and over again that having a mix of engineers and business folk, does not lead to the business folk getting the engineers to do what they want. Which is why we see so many things built in Excel and Access - the business folk know what they want, but their bosses send the engineers off is some crazy other direction. A MVP is quite often exactly what these people need to get the bosses engineers working on the right product. And often it's not enough and the business folk end up using Excel for 20 years with a string of failed products coming out of engineering.
  - datavirtue 6y ago
    You guys are all describing the root problems we have been trying to solve with Agile for decades. It's gotten to the point where tech has thrown up thier hands and just exists to bill people for running around like a headless chicken.
- fragmede 6y ago
  >If you have access to only engineers As a programmer, I'm very lucky, but none more than here. I have access to an infinite amount of programmer time. Okay, realistically that's bounded by the number of productive hours in my life, and more realistically, my level of interest in a thing. But it's easy for me to tell someone else "oh yeah, just get a programmer to do it" - because if I had those same desires, that programmer is me. But looking at the job market for programmers and the salaries commensurate with the demand for them (both in and out of the Valley), "access to a programmer" is something that many people still have to reach to get, and "learning to code" is not a quick or easy process. Honeycode isn't the first product in this space, nor will it be the last.

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.

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

nmcfarl 6y ago
It has been my experience over and over again that having a mix of engineers and business folk, does not lead to the business folk getting the engineers to do what they want. Which is why we see so many things built in Excel and Access - the business folk know what they want, but their bosses send the engineers off is some crazy other direction. A MVP is quite often exactly what these people need to get the bosses engineers working on the right product. And often it's not enough and the business folk end up using Excel for 20 years with a string of failed products coming out of engineering.
- datavirtue 6y ago
  You guys are all describing the root problems we have been trying to solve with Agile for decades. It's gotten to the point where tech has thrown up thier hands and just exists to bill people for running around like a headless chicken.
fragmede 6y ago
>If you have access to only engineers As a programmer, I'm very lucky, but none more than here. I have access to an infinite amount of programmer time. Okay, realistically that's bounded by the number of productive hours in my life, and more realistically, my level of interest in a thing. But it's easy for me to tell someone else "oh yeah, just get a programmer to do it" - because if I had those same desires, that programmer is me. But looking at the job market for programmers and the salaries commensurate with the demand for them (both in and out of the Valley), "access to a programmer" is something that many people still have to reach to get, and "learning to code" is not a quick or easy process. Honeycode isn't the first product in this space, nor will it be the last.