4 ms·

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 m

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.

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.