3 ms·

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'

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.

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.