What's Low Got To Do With It? A Low-Code Discussion
Neil Ward-Dutton posted a nice quick-take on low-code and automation: Just uploaded my third weekly quick-take video: Let's talk about low-code. What's your view? #lowcode #automation https: BP3 Global, Inc.
2 minute read
May 24, 2020
Neil Ward-Dutton posted a nice quick-take on low-code and automation:
I think Neil got it exactly right that low-code, at its core, is using a graphical drag-and-drop interface to build something that you might previously write code for.? (Unfortunately, that drag-and-drop usually comes with a lot of property sheets to fill in!)
Low-code is typically a phrase that compares to the previous approach.? Last decade's "low-code" is this decades "too much code."? Every decade or so there are new ideas about what low-code means.
In the 90's, Low-code usually meant drag-and-drop UI building in Visual Basic and similar tools.? Which was awesome (for UI-building).? It didn't eliminate code but definitely eliminated a lot of the code needed for layout. Working with other tools like NeXT's Interface Builder (people still use its successor XCode product by Apple), there were lots of effective ways to reduce the amount of hand-written code to build UI.
In the 2000's in the business application space, low-code usually meant:
Drawing workflows and processes as diagrams that run - that execute in a process engine -
Without writing code to hand work from one person to another (assignment and orchestration of work)
Without writing code to split work into parallel work streams
Without writing code to join it back together.
Without writing code for triggers, events, timers, error handling
And it was all drag-and-drop. Keep in mind, these diagrams were really writing asynchronously parallelized execution of a process of unknown duration, with abstracted notions of roles (assignment), and service endpoints.? Pretty amazing what you could do with low-code process flows, when you relate it back.
Of course, you also have low-code for integration (draw these lines between two end-points, possibly massage or cast the data types or run a transformation and voila! integration is done!
The thing about Low-code when you take it to its logical conclusion, however, is that eventually you're describing a problem that is just as complicated in low-code, as it is in code. And then there are additional problems that are actually more complicated in the low-code environment than in code.? When you see someone move a for loop into a diagram to iterate over a list, with every step in a diagram... you've seen someone go a bridge too far with low-code.
And no one who has a low-code tool product wants to hear that there are limits that don't make sense to cross.? So let's take an example from another domain.? You can use a low-code approach to lay out articles for a publication (and photos, etc).? You can even drag sections within an article. Or paragraphs. Or move a photo. Drag-and-drop was a great productivity addition to word processing.
But, would you drag-and-drop from a list of words to build your sentences?? From a list of pre-written sentences to compose your paragraphs?? No, you wouldn't. You'd just write the words and sentences you want to use to communicate effectively. It will be much faster, but it may require you to know how to type or to use dictation.
At some point, you just use the right tool for the job.? But it is hard for people to understand where to draw that line when they're paid to not see any boundaries.? And it is hard even if they're not arguing with their wallet.? And the answer is, in my opinion, when what you're doing is just as complicated or more so with the abstraction, than without it (and that is still too abstract for most people).
