Sometimes writing a full web application is the right solution, other times you just need a database with a front end and a low-code solution is best, other times an excel spreadsheet will be the right solution, and other times just physical process change is best.
Why take something out of your toolbox?
Until you need it to do something slightly beyond its capabilities and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one small feature.
This is all part of having a good level of intuition for what capabilities you are likely to need, and then picking appropriate technology.
You'll probably run up against the former quite quickly. The latter possibly never.
(In quotes because many/most no-code environments are Turing complete, but you still wouldn’t want to develop certain apps/logic in them)
I completely agree with you and this is the crux of it. Even if you know how to code, there situations where a nocode tool (like retool) is the best tool for the job
The problem isn't my toolbox.
The problem is someone elses toolbox, who often isn't an engineer, when that someone hits the limits of that shiny, sparkly tool he put in his box.
Because at that point, software engineers have to figure out how to interface some extension with that thing. Which may be easy. Or it may be next to impossible, because the tool usually doesn't have things like version control, standard interfaces other than outgoing HTTP (if it even has that), compatibility with common IDEs or the ability to unit test. Bonus points if it doesn't even store the box-and-line-diagrams in something vaguely grep-able like XML, but uses a proprietary binary format...or stores them on the vendors servers making them completely inaccessible other than through the vendors interface.
Right tool for the right job? No problem with that. If it "empowers" someone to do something he couldn't do otherwise...great, full support.
But as soon as someone wants me to interface my toolbox with it, I will demand that it offers the same qualities that I expect from every other tool that I use. Because these qualities aren't arbitrary, they evolved over decades of hard earned lessons in software engineering.
It's great because he is basically expressing his requirements in something that works.
I think just like the coders should learn the business they work in, if the business learns some code.. everyone can be a lot happier.
In the low code context I think if you can all agree to treat whatever is generated there as throwaway prototypes, then it can be a value add. Ie - instead of writing a 20 page document, I'm going to show you something that sort of works here.
The pain comes from people thinking its going to replace developers, getting stuck, and then forcing the developers into the low-code tool too.
SQL is still dreadful, apart from all the alternatives.
I also started a project to upgrade some software from some old in-house developed stuff to an SAP module (gross, but effective) and it took about 18 months just to make the development and rollout plan, since it was incoming inspection software so it was super important to get right. I left before I saw how long it took to develop, but I think that's the easy part of the whole process.
I'm more than happy creating some views in a SQL database and give business people access to a read only replica instance so they can do exploratory work on data without much involvement from engineering. I've seen so much developer time spent on generating reports for the business which takes time away from feature development.
And sure we might complain about data scientists handing us spaghetti jupyter notebooks or business analysts giving us rube goldberg excel sheets to productionize but I vastly prefer that over them telling us what they want in words. They are POCs and prototypes. It's fine if they are messy.
So if low code tools are thought of in the same vain as excel or jupyter notebooks, they can be pretty darn useful.
Why? They should already know the native language like English in the US, which is perfectly capable of describing a problem. Unfortunately, many people are poor at communicating in the native language, which is a more fundamental problem. However, how does learning another language like Python or SQL make this any better, if they are unable to use their native language sufficiently?
At least with a programming language, which is more precis e and limited and what you can express, you are forced to think more precisely the desired logic.
I've taught and gave workshops to business people on programming and database query languages for data analysis include non-SQL ones like Mongo. And I can say that those that took to time to learn the query language communicated more effectively because they can send over a query and then use English to give more context, mostly around the presentation layer.
On the contrary, being forced to clarify your thoughts under the constraints of a formal language, and be able to execute and test them, helps tremendously to figure out what you actually can do and want to do, even more so when the problem is complex (and excluding already well understood tasks).
It's as if we lumped together the creation of everything "made of wood" as similar. Shelf, doll, table, boat, grandfather clock...
Google Sheets is of course a little more than Excel, but the fact that large sites are still going this route and seeing success is legitimately impressive.
You could make programming less complex but it doesn't obviate the need for making those low-granularity decisions -- you're just choosing to go with the "defaults".
I write a DAW, and we face two major fundamental problems:
1. most DAW users don't use many features, but they do tend to use different sets of features. So if you want to be useful to lots of users, you need a LOT of features.
2. the corollary of (1) is that there are, unlike in "business logic" applications, oodles of workflows in use, and the application needs to support as many of them as possible without friction or bugs.
Programmers make a ton of "implementation detail" type decisions but they also make a ton of decisions that affect the abstract definition of the thing, and these I define as "business logic".
If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic".
With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.
Of course a DAW can probably be viewed as a low code tool for programming sound - so implementing a DAW is more similar to implementing a spreadsheet - than using a spreadsheet.
Still, the user has a goal, a process of achieving that goal - and the software needs to support the process and achieving that goal - eg output a track.
The fact that there are many users, with different goals and processes - doesn't mean that it's not "business logic" both to "crossfade" and "shift pitch".
This doesn't apply to creative apps. Do this then that, or that then this, or the other and then that and the other other, etc, etc.
> It's still "enter data/modify data" along with suitable UI/ux and views to enable that.
While I agree that this is technically true, I'm not sure anything useful comes of viewing things in this way. Undecided, but doubtful.
> Still, the user has a goal, a process of achieving that goal
This just isn't true. Talk to creative people. Even someone doing a task like audio mastering, which is not particularly creative, doesn't begin with a goal. Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. That will change over time as they work on a piece and the process coalesces into "I'm trying to ..." as opposed to the earlier stage of endless "let's try ..."
Wikipedia gives the following definition for "business logic"
> In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
I (and i believe op) lean on the "domain logic" end when talking about business logic.
So the fader toggles bits in the raw data, but in a way that input and output is sound data that can flow through the application. Your DAW needs both the bit fiddling - and the "flow input through the fader and out to file" parts.
> Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish.
I'm talking much more abstract here - "improve recording" is a goal - there's a current domain state, and the goal is to modify it in some way. I'm talking about user intent in interacting with the domain.
> the real-world business rules
what are these for creative apps, and where do they come from?
So you can record sound, store it in a "track", transform it to "mono" etc?
> ... It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
You might store the sound as a wav, export it as an mp3 - the undo tree might be in SQLite...
Ed: might make more sense with the term "domain"; domain logic, domain rules.
Ed2: somewhat tangential, but see also the original model-view-controller-(user) paper - the user holds a mental model of data/objects in the domain - and the application holds raw data in ram/disk - the UI needs to bridge these two domains so that a user can "apply reverb" from the domain concept to the actual data model (modify a wav file).
https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...
The problem with spreadsheets is that they end up with 5 lines of formula code wrapping over a fullhd+ screen. If it was a regular code, which isn’t hard to write at all, they could grow much further and get help from professional developers. When I see that 5-line formula, I say “sorry, you have to figure it out by yourself”.
What low-code should actually be is what we called RAD back in the day. Excel is a good idiom and a platform for doing things. But its language actually sucks. What regular people are afraid of is boilerplate and wheel-engineering, not code itself. I disagree with the second paragraph. Most of our “starter” complexity is highly incidental, in a sense that we always start in a forest, cold and naked.
I don’t know of a good equivalent replacement that people can use today with such a low entry level.
Excel covers a lot for many people.
For a lot of tasks, this is actually true. Take away the requirement to write code by supplying them with a low code tool, and suddenly people can do lots of useful things that they couldn’t before. So in that respect, it’s no lie.
But of course, there are a tonne of other situations, where code is not the only complexity present. Sometimes you’re just trying to solve a big, complex problem. Take away the coding requirement, and you’re still left with a tonne of complexity to manage. And low-code tools aren’t the best for handling that. In those cases, you’re better off hiring developers.
I’ve seen a few people build very complex things using low code tools. Modern ones, but also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools.
But that doesn’t mean low code tools are useless – they are great for the first set of problems, where the code required is just incidental complexity. You shouldn’t write off this substantially useful product category just because people get into trouble using them for problems they aren’t suitable for.