Live data from Hacker News

The “No Code” Delusion

alexhudson.com

11–20 of 334 posts

Re: The “No Code” Delusion

#11
post #4

"Low Code" is currently where it's at. Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform. Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services. It's been happening since Excel, through to Wordpress and nowaday…

That is because we've built tools that are good enough for most use cases, and the cases don't actually differ all that much. For every new case however, new software has to be made. It isn't getting any easier, there is just more of it now.

The problem is that a "problem" is essentially a fractal; it needs a defined accuracy and scope to be solvable. Differing scopes and accuracies again require overhauls of software that would otherwise be acceptable for the same task.

Re: The “No Code” Delusion

#12
I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential architectural patterns of software development a novice will paint themselves into a corner before they even know what they are doing, requiring an expert to come in an clean things up.

Re: The “No Code” Delusion

#13
I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas."

And that's how I view my job as a software developer: clarifying ideas.

Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools to programmers of some sort.

Re: The “No Code” Delusion

#14
post #12

I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential archi…

Nearly 40 years for me; I remember reading about The Last One [1] back in 81.

[1] https://en.wikipedia.org/wiki/The_Last_One_(software)

Re: The “No Code” Delusion

#17
post #12

I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential archi…

I'm actually quite fond of some "no/low code" tools but there is a threshold of complexity beyond which if you use them then terrible abominations will result that are far more complex then the equivalent code and actually require more technical expertise then 'code' - so you end up with components that only a skilled developer can maintain in a platform that developers will hate.

Re: The “No Code” Delusion

#18
I agree with the author in all points about the no-code movement and goals, but disagree with the larger points about software development and engineering in the business setting.

In particular, the attractiveness of no-code should not be that one does not have to have in-house software development, but that one has less technical debt and thus smaller technical interest payments. Businesses will always have problems with computers, because computers are rigid and unyielding, while businesspeople are soft and compromising.

It is all to easy to read the beginning few paragraphs as the sourest of grapes: The businessperson, having embraced fax, email, paperless, Web, and mobile, is nonetheless no closer to having embraced computer. The "traditional sense" of creating software is derided as "expensive, in short supply, and fundamentally [not quick at] produc[ing] things." But that is all explained neatly by market forces: Developers are expensive because competency is rare because understanding is low because computerizing is a painful commitment because operationalizing a business is equivalent to automating it away. Computers reveal the rent-seeking and capitalization simply by being themselves on their own.

Re: The “No Code” Delusion

#19
post #9

This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs. The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...). Especially with tools like Helm I be…

Thank god trends like Pulumi and the new AWS sdk is emerging.

General purpose programing languages are getting more expressive by the day, why do we use data serialization languages instead for configs? it doesn't make any sense.

Configuration is code not data.

Re: The “No Code” Delusion

#20

I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas." And that's how I view my job as a software developer: clarifying ideas. Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools…

There are plenty of tools that help us in clarifying our ideas though. Take mathematical notation for example. Or music notation. Or a CAD program.

All are examples of domain specific tools that allow the user to specify their intention in a non-ambiguous way. And they also allow the user to think about and experiment with the problem space.

I think what we need is something akin to this. The "business logic" that we are talking about here is to me a non-infinite domain. It should be possible to boil it down into a domain specific tool that is more helpful than a general purpose programming language.

Post reply on HN