Hacker News new | past | comments | ask | show | jobs | submit login

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




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


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!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: