5 ms·

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 exa

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.

no_butterscotch 5y ago
To your experience I wonder if some of these low-code/no-code platforms are succeeding because of successful salesmanship and networking rather than technical merit. Similar to how vendor A can wine and dine the right person from firm B to get the firm to adopt vendor A's tech, rather than having the right internal people vet the solution. It isn't the developers that are pitched. It is the people over the heads of the developers, this seems to be crucial.
- kitd 5y ago
  Just like the 4GL products of the 1980s. That and knowing which C-suite exec to target.
- marvin 5y ago
  Microsoft's SharePoint went through this exact same routine ten years ago. The salespeople loved it, the customers bought it and the tech folks trying to implement the customer's needs were tearing out their hair and delivering super expensive and super terrible solutions.
  - usrn 5y ago
    I've never developed anything with SharePoint but I've used apps made with it. You can tell that's going on from the outside.
- ako 5y ago
  Ofcourse, that is how professional product organizations work. They define user personas and buyer personas, and then make sure they have a compelling story and features not only for the user personas, but also for the buyer personas. It's not about wining and dining, but about knowing what your buyers value in the products they buy. For low-code, buyer personas value time-to-market and reducing dependency on limited available software engineers. Management often has more software needs than the IT organization can deliver, and new engineers cannot be found easily, so they look for other ways to build the software they need.
  - zozbot234 5y ago
    > Management often has more software needs than the IT organization can deliver, and new engineers cannot be found easily, so they look for other ways to build the software they need. That may be the case, but building a huge, crumbling pile of "low code" or "no code" technical debt is not a sensible way of "reducing dependency" of engineering.
    - ako 5y ago
      It doesn't have to be a huge crumbling pile of debt. It's just a tool that can be used to create useful applications if used in the right way. I think of it as a visual IDE to build opinionated apps, i.e., visual ruby on rails or visual django. It will significantly improve your productivity on repeatable tasks (crud pages, domain model to tables, querying, etc), and you can usually add custom coding for those things that aren't handled by the low-code platform. Or you write a separate service for those parts and call these through REST.
victor9000 5y ago
Sounds like technical leadership failed both you and your company.
tragomaskhalos 5y ago
We had a somewhat similar situation: - Client has complex-ish billing rules that need to change periodically - Their desire was a system that would allow business bods to implement new and modified rules without pesky IT involvement - Client was demoed a low code / visual programming tool, and fell in love - We were brought in to team with the company that produced said tool to deliver the system - client's IT department were Java-oriented, but were specifically overridden by the business for this project ! Well, we delivered, but the emergent reality was very different: - It became clear very early on that the tool required specific programming skills and training, and there was zero chance a non-programmer could make any headway - Because of the limits of the tool, the codebase ended up far more intractable and complex than it would have been using a regular language / setup - The tool required regular version uplifts, which necessitated some code changes and other shenanigans, all extra ongoing cost on top of the licence fees - The only people who could do anything with the tool were consultants from the company that made it (and a few of our folks who did training) - vendor lock-in with a vengeance In a bitter irony, for test purposes I wrote a parallel implementation of the billing rules in Ruby, using that language's superb DSL capabilities, and that was a million times clearer and more maintainable. If I had a time machine, I would go back and persuade the client to instead go with a Java solution with Groovy to do the billing rules, as its DSL capabilities are on a par with Ruby's.
Existenceblinks 5y ago
I see every command to tell computer to do thing is a YesCode, neither low or high, it's code. A form button click is akin to assembly `interrupt`, instead of doing routine with data in registers, UI event tells servers to compute data from form inputs. It's all programming languages in different styles. The so called low-code is just poor programming language. If I create a language whose only feature is `print` without debugger, I can call this low-code as well.
- ako 5y ago
  It's not all poor programming. There's a lot of repetition in software development. If you can find the right abstractions you can make software engineering a lot more efficient. This works, regardless if you visualize the abstraction or you put it in a function in a library.
  - Existenceblinks 5y ago
    > if you can find the right abstraction That is not going to be "low-code". The right abstraction is a bunch of small modules and functions. Visual programming is not low-code.
    - ako 5y ago
      Actually it is. Most of the low-code vendors simply visualize high level functions using some sort of BPMN visualization.
      - Existenceblinks 5y ago
        What's different between code and low-code definition?
        ako 5y ago
        I'd say that in an ideal situation low-code is a visual DSL that lets you declare in business terms what you expect the application to do. Kinda like pseudo code that you would expect from a business analyst, that only defines what business outcomes you expect, but technology independent. So it could still be implemented in react native, or veujs, or angular, or native swift.

no_butterscotch 5y ago

To your experience I wonder if some of these low-code/no-code platforms are succeeding because of successful salesmanship and networking rather than technical merit. Similar to how vendor A can wine and dine the right person from firm B to get the firm to adopt vendor A's tech, rather than having the right internal people vet the solution. It isn't the developers that are pitched. It is the people over the heads of the developers, this seems to be crucial.

kitd 5y ago
Just like the 4GL products of the 1980s. That and knowing which C-suite exec to target.
marvin 5y ago
Microsoft's SharePoint went through this exact same routine ten years ago. The salespeople loved it, the customers bought it and the tech folks trying to implement the customer's needs were tearing out their hair and delivering super expensive and super terrible solutions.
- usrn 5y ago
  I've never developed anything with SharePoint but I've used apps made with it. You can tell that's going on from the outside.
ako 5y ago
Ofcourse, that is how professional product organizations work. They define user personas and buyer personas, and then make sure they have a compelling story and features not only for the user personas, but also for the buyer personas. It's not about wining and dining, but about knowing what your buyers value in the products they buy. For low-code, buyer personas value time-to-market and reducing dependency on limited available software engineers. Management often has more software needs than the IT organization can deliver, and new engineers cannot be found easily, so they look for other ways to build the software they need.
- zozbot234 5y ago
  > Management often has more software needs than the IT organization can deliver, and new engineers cannot be found easily, so they look for other ways to build the software they need. That may be the case, but building a huge, crumbling pile of "low code" or "no code" technical debt is not a sensible way of "reducing dependency" of engineering.
  - ako 5y ago
    It doesn't have to be a huge crumbling pile of debt. It's just a tool that can be used to create useful applications if used in the right way. I think of it as a visual IDE to build opinionated apps, i.e., visual ruby on rails or visual django. It will significantly improve your productivity on repeatable tasks (crud pages, domain model to tables, querying, etc), and you can usually add custom coding for those things that aren't handled by the low-code platform. Or you write a separate service for those parts and call these through REST.

victor9000 5y ago

Sounds like technical leadership failed both you and your company.

tragomaskhalos 5y ago

We had a somewhat similar situation: - Client has complex-ish billing rules that need to change periodically - Their desire was a system that would allow business bods to implement new and modified rules without pesky IT involvement - Client was demoed a low code / visual programming tool, and fell in love - We were brought in to team with the company that produced said tool to deliver the system - client's IT department were Java-oriented, but were specifically overridden by the business for this project ! Well, we delivered, but the emergent reality was very different: - It became clear very early on that the tool required specific programming skills and training, and there was zero chance a non-programmer could make any headway - Because of the limits of the tool, the codebase ended up far more intractable and complex than it would have been using a regular language / setup - The tool required regular version uplifts, which necessitated some code changes and other shenanigans, all extra ongoing cost on top of the licence fees - The only people who could do anything with the tool were consultants from the company that made it (and a few of our folks who did training) - vendor lock-in with a vengeance In a bitter irony, for test purposes I wrote a parallel implementation of the billing rules in Ruby, using that language's superb DSL capabilities, and that was a million times clearer and more maintainable. If I had a time machine, I would go back and persuade the client to instead go with a Java solution with Groovy to do the billing rules, as its DSL capabilities are on a par with Ruby's.

Existenceblinks 5y ago

I see every command to tell computer to do thing is a YesCode, neither low or high, it's code. A form button click is akin to assembly `interrupt`, instead of doing routine with data in registers, UI event tells servers to compute data from form inputs. It's all programming languages in different styles. The so called low-code is just poor programming language. If I create a language whose only feature is `print` without debugger, I can call this low-code as well.

ako 5y ago
It's not all poor programming. There's a lot of repetition in software development. If you can find the right abstractions you can make software engineering a lot more efficient. This works, regardless if you visualize the abstraction or you put it in a function in a library.
- Existenceblinks 5y ago
  > if you can find the right abstraction That is not going to be "low-code". The right abstraction is a bunch of small modules and functions. Visual programming is not low-code.
  - ako 5y ago
    Actually it is. Most of the low-code vendors simply visualize high level functions using some sort of BPMN visualization.
    - Existenceblinks 5y ago
      What's different between code and low-code definition?
      - ako 5y ago
        I'd say that in an ideal situation low-code is a visual DSL that lets you declare in business terms what you expect the application to do. Kinda like pseudo code that you would expect from a business analyst, that only defines what business outcomes you expect, but technology independent. So it could still be implemented in react native, or veujs, or angular, or native swift.