[HN Gopher] When No-Code Stops Scaling (2020)
       ___________________________________________________________________
        
       When No-Code Stops Scaling (2020)
        
       Author : andrewedstrom
       Score  : 24 points
       Date   : 2022-04-23 04:57 UTC (18 hours ago)
        
 (HTM) web link (head.ai)
 (TXT) w3m dump (head.ai)
        
       | kclay wrote:
       | We have been evaluating how to scale our company (software
       | agency) to be able to quickly build out mvps for some of our
       | projects. The topic of no-code has come up and the one product
       | named Unqork[1] has been mentioned to us. Has anyone had success
       | with these solutions, if so what type of projects have this no-
       | code paradigm excelled at?
       | 
       | [1] https://www.unqork.com/
        
         | seibelj wrote:
         | I don't think no-code exists. It is a fools errand. No matter
         | what the tools are for your profession - Photoshop, Unity,
         | SolidWorks, Wordpress, or some new No or Low-code stack - you
         | will quickly realize that having someone skilled in the tool is
         | extremely desirous. For software development that person is a
         | software engineer.
         | 
         | This no-code thing has existed forever. It's a base set of
         | software that is customizable as needed to fulfill the needs of
         | your specific use-case. The rebranding to something that
         | _never_ requires custom work is once again a big lie.
         | 
         | Any sufficiently advanced tool eventually recreates the act of
         | programming - putting pieces of building blocks together
         | logically in advanced ways to fulfill a task. Dragging widgets
         | around and typing conditionals in form elements is just another
         | (slower, worse, more error-prone, restrictive) way of
         | developing applications.
        
           | toomuchtodo wrote:
           | Having seen businesses refactor out from low/no code
           | providers to their own code base once there is traction, the
           | value is in the product market fit discovery without shelling
           | out to build a full blown app stack before you have traction.
           | Fundamentally, it's about capital efficiency.
           | 
           | By all means, if you have the skill set and are confident to
           | get there without a workflow tool, do so, otherwise (maybe
           | you're biz and product heavy vs tech capability heavy as a
           | team) prove it out and then invest in your tech stack. As the
           | saying goes, you're not writing code, you're solving business
           | problems for money. If you don't have to write code to solve
           | the problem, don't (or write as little code as possible).
           | 
           | TLDR your workflow tool is either the equivalent of scripts
           | run by cron but more accessible to the team or a spike you
           | intend to clean up and operationalize long term. Treat it as
           | such.
        
       | ecshafer wrote:
       | I was at one point on a team building out infra integration with
       | Appian, which touts itself as a low-code / no-code platform. The
       | sales pitch is the no-code example which executives really love,
       | and the pitch is that they can get some "business minded people"
       | to write the "low-code". But the complexity was enough that we
       | ended up throwing a bunch of junior software developers and
       | hiring consultants for it, so you ended up with something like 25
       | software developers on a "low code" platform.
       | 
       | The "low code" option, which isn't really less code than just
       | writing it in a terse language like python (so really only code
       | compared to java). So for this company moving to Appian, we ended
       | up writing a ton of integration work in Java, and tons of AWS
       | services. Then with a bunch of custom, vendor locked, appian
       | language for their platform. And in the end we could have saved
       | money if we had just rewritten the whole platform on AWS for our
       | own use case using just a rules engine in postgres and some
       | service.
        
       | kagia wrote:
       | Oddly specific numbers, 50k records take 5minutes?
       | 
       | What was the authors methodology?
        
       ___________________________________________________________________
       (page generated 2022-04-23 23:01 UTC)