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

"The end result is always back to code."

Yes, and: you understate the downside.

While No Code (nee Visual Programming, CASE Tools, whatever) may handle 90% of the use cases, the remaining 10% become dramatically harder. Because now you're fighting the framework. Which is an angry 800lb gorilla sitting between you and your work.

Faced with the same challenge, I went in the opposite direction.

Typical strategy of BizTalk, Talend, SeeBeyond, many many others is some kind of patch cord flow chart style programming, with Access VBA style event hooks for script extensions.

I created a stupid simple framework and API optimized for our domain (medical records). Think serverless computing and awesome DOMs for HL7 and adjacent data formats.

Onboarding for our SeeBeyond-based projects was 3 to 6 months. Using my stack was 1 to 2 weeks. (One of the weeks was teaching healthcare domain experts some Java, Eclipse IDE, and version control.)

Further, in my experience, none of these No Code solutions have useful exception handling, logging, fault/error recovery, and other misc devops type stuff. So are an absolute nightmare to support in production.




The remaining 10% become dramatically harder. Because now you're fighting the framework.

That is a great point. Whenever I've tried a no-code solution I end up dropping it and going back to code. Some insurmountable roadblock appears that if I had started with code I won't be in this mess.

I've also made the mistake of recommending no-code solutions to my business - trying to reach for the golden ring of self-sufficiency. Seems great at first and then you end up trying to "debug" a no-code framework that you have little of no insight into.




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

Search: