| > No code hits a barrier when UI and DB requirements diverge. Yup. Yes and: You'll eventually have to drop down to code. For all dangly bits, that last 5% of fit and finish. Then you're fighting the framework (tool). Completely negating the benefits of the "no code", visual design tools, patch cord programming, etc. -- I did A LOT of data munging for healthcare. Starting in the mid aughts, that generally meant "HL7 interface" and "orchestration" engines. Whatever that's supposed to mean. SeeBeyond (JCAPS), BizTalk, InterfaceWare, Talend, etc. A handful of others. Each was worse than the last. Though none was worse than InterSystems Caché. (And all that "Web services" nonsense like SOAP and WSDL; so awful.) It'd take us 3 months to onboard experienced devs. Totally impractical. -- My solution was to create simple, typesafe, bulletproof APIs and tooling. For data munging, by analogy, it was like working with DOMs instead of wrestling with strings and innerHTML. All the networking, queues, retry, errors, logging, tracing, etc. was done by the tool. For the developer, everything just looked like a loose file. So the same code that worked on a directory of local test files would work as-is as the service. Made coding and debugging super easy. A bit like what AWS Lambda would look like, if it was both useful and usable. End result was 1 or 2 weeks onboarding, depending on prior experience. New hires were writing and deploying real code to production by the end of our training. And left with all the tools and skills to be self-sufficient. Actual "interface" code was easy enough to understand that we could do live review with BAs and customer liaisons. Make fixes together. Deploy code updates to prod in seconds. Our improved tooling greatly improved the team "culture" of working together. Changes requests just became conference calls. Which, of course, beget a lot more additional contract work. (No good deed goes unpunished.) |