tempacct3575

hace 4 añosdiscuss

Yeah, text transforms are a bit of a nightmare in almost every platform. Most low code platforms have an expression or macro/function editor that would be used to deal with those - it's also ugly there. For my team, we usually cleaned them up in the back end services since citizen developers are not too familiar with these kinds of issues.

tempacct3575

hace 4 añosdiscuss

I work at a large healthcare equipment manufacturer - the group I worked with automated many business processes relating to equipment field sales, service, and maintenance. The end users were generally internal sales or field techs. Most of the apps are basic CRUD and maybe some video links. We're a typical large enterprise, so it takes a very long time to execute new software projects and often by the time they are done the business needs have shifted.

The users started out by using MS Power Platform and SharePoint to create simple apps and forms and get some feedback from the users. After a couple of iterations they would finalize the desired flow and my team would give them an enterprise integration point (sometimes Boomi, sometimes custom code) to read/update the real data. We are currently evaluating Mendix and Outsystems to see if that will further streamline the process.

tempacct3575

hace 4 añosdiscuss

UML did fail as a modeling tool - it was just too complex. However, flowcharts have succeeded on many platforms in many domains. (Gaming engines like Godot Visual Script and Unreal Engine Blueprints, BPM tools, Enterprise Integration tools, many hardware design tools)

The best environments combine visual and code based elements so you don't get "stuck" when something is missing in the low code areas.

tempacct3575

hace 4 añosdiscuss

> I just don't buy the argument that visual programming tools are inherently more creative or imaginative than text-based programming tools because at some point, you are going to be constrained to the UI, which always comes with tradeoffs.

They aren't inherently more creative for all people. For example there is a group of people that prefers LaTeX to MS Word - but it's undoubtable that Word is more accessible to more users. The creativity comes from letting business users directly iterate on the UI mockups and underlying process, which is possible in these tools. Instead of waiting a few months for an IT project to start, the users can create a mockup in a few days and iterate a few times before connecting to a real backend. I would have thought this was improbable 3 years ago, but personal experience has taught me that there are many business users capable of doing this.

Most of the tools created with these platforms never "ship"; the primary users are often internal. At large companies, an internal app may have 10k users. Also, YMMV depending on the tool - some are much better than others at debugging complex flows.

tempacct3575

hace 4 añosdiscuss

The main reason I despise it is that the term is often used to imply that there is "no technical debt" or "no maintenance costs" or that this is "not real programming". In reality, users are still creating software, so technical debt and other maintenance costs will still build over time. Project management, feature prioritization, data/schema design, system design, module decomposition, testing, etc are all still important tasks and don't go away just because the tools are visual.

A lot of it is due to perceptions - in my experience senior non-tech managers misunderstand the term, whereas "visual programming" still emphasizes that this is a software project with all that entails, just constructed in a more accessible way.

tempacct3575

hace 4 añosdiscuss

I've worked with several of these tools: Power Platform, Mendix, and Outsystems.

I despise the terms no code-and low-code. A better term is "visual programming" (as an alternative to text based programming). You should still follow some basic software development principles - Outsystems training in particular is excellent in this regard.

There definitely is an appetite for these tools. There is a class of business/operations people who know how to manipulate flowcharts, Excel macros and some MS Access but struggle with source code. I have worked with several team that successfully automated some processes using these tools, and were often able to create a pretty good user experience as well.

There is also no risk of this displacing developers - in my experience these tools open the imagination of what is possible and even more backend support is needed over time. Developers work on core capabilities and systems (which change slowly) and users work on creating the custom business process (which change often). With the right management it works quite nicely.

comments