Hacker News Reader

I work for a guy now who basically picked up some coding in his 30s because he found the previous business team he was on was more successful because of it. His code isn't great, but he can express what he wants in giant SQL blobs and then we can build scalable solutions against basically his mockups. He can also unblock himself for a while with his own code while we build the real production flavor, etc.

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.

Yep, I'm working with a guy on the business side who is amazing with Dash. It's the best example of a skill set being greater than the sum of its parts that I've seen.

CTE was a game changer for regular business people I work with being able to express what they want in SQL.

SQL is still dreadful, apart from all the alternatives.

In these scenarios these low code tools feel like the evolution of excel. How many times did people who couldn't write full on apps throw something together with some excel formulas to do a version of what they needed?

At a previous company, where we developed and built medical devices that were not just a toothbrush, we couldn't install or build any software that did anything that made almost any decisions about the design or production of the devices. In other words, we were stuck using Excel spreadsheets to make decisions then we had to validate the decision and sign off on it as the human who was deciding. Basically, we could build prioritization and tracking "software" out of spreadsheets, but anything other than that, such as the software used to log inspections, had to go through the same process our medical devices went through in order to be used for the design or manufacture of the actual devices. Excel was an absolute life saver there for at least the stuff we could use it for!

Yup. The rule of thumb I learned was that at a FDA regulated facility, "anything that touches the product" is regulated just like it's the product. And when the FDA audits a facility, they focus primarily on software.

Yep, and for one spreadsheet that prioritized some work, we had to show the FDA that the spreadsheet didn't materially affect the devices we were manufacturing. Basically, this particular one just told us which lots of goods to inspect first, so at worst case it would have just slowed down our line, not affected the device's quality. We still had to take 1 hour to walk some inspectors through our use of it, and why it wouldn't fuck things up.

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 don't think I could do FDA software, it sounds so painful. Same with voting machines that are properly regulated (had a CTO at one point who previously did that sort of work and he had stories to tell). Fintech is hard enough.

How many times have people who can write code spent many weeks on something that could be done in excel in an afternoon?

This was (and may still be) the foundation of tax software: domain experts in each province specifying tax formulas in a spreadsheet with an interpreter that takes those formulas and translates it to code libraries in Java, C, C++, etc.

The problem with throw-away prototypes is that often don't get thrown away and become the actual system. 'Hey it works, mostly, why spend money improving it?'.

No tool or paradigm will solve the problem of working for morons.

I spent a couple of years not that long ago basically wrapping a proper production system around a low code system because it had grown so complex by the time I joined that trying to just do a rewrite was not feasible in a reasonable amount of time given our small team. Instead we built two-way sync of the data and built new functionality in a proper system and gradually replaced function by function when we could justify the time cost.

I honestly believe everyone working at a tech company should know or learn how to code even if it's just SQL or basic Python.

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.

> I honestly believe everyone working at a tech company should know or learn how to code even if it's just SQL or basic Python.

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?

While I agree that English or any other spoken language is sufficient to describe technical requirements, many people have trouble communicating what they actually want because the language itself is very forgiving and so there is room for misinterpretation.

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.

This articulates well something that's always been in my mind - code is just a precise expression of business logic. Programmers are actually business administrators making low granularity business decisions.

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 understand your point, but I really intensely dislike the term "business logic" when used as some sort of universal. A bunch of us write code that nothing to do with any "business logic", even if there is some other sort of set of workflow rules & design that need to apply.

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.

I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granularity sense (point 1), but you also need to define what it does at lower levels of granularity. What you define at those lower levels is still part of the the abstract model of the DAW. Hence it's "business logic". Whether you use a while-loop instead of a for-loop, that's not business logic but an implementation detail.

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".

The point is there isn't really a "thing the program should do".

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.

It's still "enter data/modify data" along with suitable UI/ux and views to enable that.

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".

"Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values.

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 ..."

> "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values.

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.

From the wiki quote:

> the real-world business rules

what are these for creative apps, and where do they come from?

> ... determine how data can be created, stored, and changed.

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...

It's true that it's a bit of an expansion of the word "business", but it doesn't really mean "something to do with commerce". It's just the parts of the code that handle the rules of the system that directly enable the user's goals, and not any of the auxiliary, supporting infrastructure. So for a DAW business logic is pretty broad, true, but it would be stuff like, faders or muting a track and the effect on the mix, whether you can copy-paste a snippet of audio, and routing audio through plugins. And not things like the file format of a project, or the code that interprets hardware interfaces.

this is a failure of abstraction. over time, the platform detail handling gets separated into the runtime (for example memory management, now cloud provisioning, my startup is a language that abstracts distributed state). the reason we get ahead of the abstractions is that software is so valuable that we will spend $100M to bring a product to market by force of capital and its worth it because historically the winner takes most, this is just economic imperialism/conquering and barely a level removed from physical violence. it is sad actually how self interested we all are, imagine the world if we could figure out how to cooperate!

Totally agree - right tool right job.

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?

>other times you just need a database with a front end and a low-code solution is best

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.

That's the same thing with all technology choices though - if requirements change substantially you always risk a rewrite. If write a full-code application with all your logic in server-side .NET and suddenly your users have a requirement to use it offline, 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 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.

There is a vast difference between the things which are blocked because youre not using a turing complete programming language and things which are blocked because of the nature of that language though.

You'll probably run up against the former quite quickly. The latter possibly never.

Yeah but ‘Turing complete languages’ have their own limitations compared to no code, like being comparatively slow to develop in.

(In quotes because many/most no-code environments are Turing complete, but you still wouldn’t want to develop certain apps/logic in them)

> Why take something out of your toolbox?

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

> Why take something out of your toolbox?

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.

>some people think that the difficulty in implementing something is because it requires code

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).

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.

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.

Right? Broadly, it's kind of funny how people lump everything involving computer code together as if they are equally difficult.

It's as if we lumped together the creation of everything "made of wood" as similar. Shelf, doll, table, boat, grandfather clock...

If you can translate business reqs into a (working) technical impl you're a programmer - the rest is semantics imo.

VB6 was a fantastic tool that managers with really bad programming skills could make useful fully functional products.

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.

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.