The “No Code” Delusion
alexhudson.com
The “No Code” Delusion
1–10 of 334 posts
Re: The “No Code” Delusion
#2Re: The “No Code” Delusion
#3E.g. if you could get the end product with Less waiting and miscommunication. I can see that being a sales pitch that resonates
Re: The “No Code” Delusion
#4Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform.
Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services.
It's been happening since Excel, through to Wordpress and nowadays splintered into 100's of directions and platforms from Wix to Podio to Notion.so
Re: The “No Code” Delusion
#5For instance, "no-code" website creation offering has done wonders in replacing the "install wordpress on a very crappy cheap host and let it rot with vulnerable plugins" paradigm.
Re: The “No Code” Delusion
#6Is it no code or no programmer that’s the goal. The latter seems reasonable if you’re software product customer that would like to trim out the person between you and the product that seems to be slow only to misunderstand what’s needed. E.g. if you could get the end product with Less waiting and miscommunication. I can see that being a sales pitch that resonates
That seems to be the gist of it. SaaS seems to tackle this specific issue by trying to move everything away from the customers in the first place. Don't need sysadmins or software devs(here) if they're in the cloud(over there).
Their pricing model is often advantageous to smaller companies aswell; only paying for what you use, even if that price is ridiculous per unit sold, it still often beats hiring dedicated staff. This effect lessens over time as company grows.
Re: The “No Code” Delusion
#7Re: The “No Code” Delusion
#8Sure you can replace 4-5 lines of python with some box-based UI rule system, but anybody who’s not first week out of a 2 week coding boot-camp knows that the devil is in the detail. What if instead of “display error” it’s “try again if it’s a mail server error up to a maximum of 4 tries then email the administrator and save debugging info”
Then what about a loop? Have you ever tried to debug a loop in a UI programming environment? What about a complex loop with custom data types and no ability to see a stack trace or variable list? You gotta put print dialogs and system exits all over the place, and oh, the print dialog only prints a small string? Now you gotta do 1 variable at a time, 200 times to debug. Now I’m showing this to the “non-coder” who’s thinking “this is a giant headache” - and you know what??? HE IS RIGHT, because we have both been forced to use this crappy, blunt tool. Wasn’t this supposed to make things EASIER? Now the business guy AND the programmer are tied up trying to shoehorn what would otherwise be trivial for the programmer into this weeks novelty rinky-dink “no code” tool
Ui drag and drop replacements only work for trivial examples, or they become a giant unmaintainable spaghetti diagram that’s so complex you can’t even follow the lines, let alone understand program control flow.
The fundamental problem with existing software is composability. Us geeks have it at the command line, but regular users can’t pipe their brower through grep them to their printer,
Users are stuck with the fixed options available at software design time, if we could standardise a composable interface on all software (I don’t think “bytes” is the right abstraction for this, it’s too low level) then users can start dynamically composing their own solutions, which will take a decent shift in thinking for most people - but a generational cycle will fix it if young kids grow up taking composability for granted
Re: The “No Code” Delusion
#9The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...).
Especially with tools like Helm I believe we reached peak insanity levels. Instead of using a general purpose or configuration-specific (like Jsonnet/Cue/Dhall) programming language to build and then emit in-memory objects to YAML manifests, the industry is using YAML to define templated YAML and then parametrize this templating with even more YAML.
Now we just write complex declarative configuration with no debugging facilities, a non-existent type system, inversion of control that usually ends up working against us and no way to interact with external data apart from stringing everything together with fragile shell scripts. But hey, there's no need to write a single line of Go/Python/Java/Ruby!
Re: The “No Code” Delusion
#10Programmers never go away, though. Besides the need to write the customizations that the higher level languages miss, there is the need for disciplined thinking and testing. No matter how simple the tools become, the need for these remain.