Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The “No Code” Delusion

alexhudson.com

Post reply on HN
Print view View original

251–260 of 334 posts

Re: The “No Code” Delusion

#251

Post by Bartweiss »

coffee wrote: post #226
honkycat wrote: post #219

My response to "No Code" solutions: If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible. There is no secret programmer cabal where we are holding hostage the REAL tools we use to develop software, and we keep them secret and hidden while we fuck around every day. For someone to develop a…

> If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible. Not really. As we evolve software development, historically, we've done this through adding new layers of abstraction. Assembly --> C --> Interpreted Code (Java, Ruby, etc...) Why isn't the next layer of abstraction simply what is bei…

> Why isn't the next layer of abstraction simply what is being termed as "No Code" today?

Cynically? Because people were also selling "no code" ten years ago, or even further back.

I know that sort of inductive argument doesn't actually work. We went through a dozen nonsense models of infections, but germ theory was actually correct in the end. AI has seen frauds and baseless hype since the mechanical Turk, but there still came a point when computers won at chess and Jeopardy. But it's a pretty good warning sign.

The gradual progression of abstractions still caps out somewhere around Python and Rails. We have drag-and-drop website makers, and visual tools for "plumbing" ML flows backed by pandas, or engineering calculations backed by Matlab. They mostly work, and people who know the underlying tools sometimes use them for speed while mixing in actual code as needed.

Meanwhile, promises of codeless business apps don't seem rooted in any of those advances, and continue on from their dysfunctional predecessors. And people actually making business apps in a hurry pull from NPM or PyPI without ever touching "no code" tools. It seems like we might get much closer to that layer within a decade or so, but I don't think we're there yet.

Re: The “No Code” Delusion

#252

Post by leggomylibro »

sequoia wrote: post #140

I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed application development up 10x. My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor: Imagine you have to pick a bike to go on a trip. You're travelling on a wel…

We used to make this sort of analogy a lot at a web dev place where I once worked. Eventually it got boiled down to a pithy joke: "Ruby on Rails is great, but only if you stay on the Rails!"

Re: The “No Code” Delusion

#253

Post by 0x8BADF00D »

I always thought "no code" was a meme. Best example of "no code" were the traders I used to support working at a bank, they had these massive Excel sheets with weird macros that would break in non-deterministic ways.

Re: The “No Code” Delusion

#254

Post by Aperocky »

sequoia wrote: post #140

I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed application development up 10x. My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor: Imagine you have to pick a bike to go on a trip. You're travelling on a wel…

The only problem is, it’s actually not a road bike, but a shopping cart. The advertisement is that you can sit and not pedal (when down hill). And it’s not faster in any case.

Re: The “No Code” Delusion

#255

Post by heelix »

smhenderson wrote: post #149
sequoia wrote: post #140

I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed application development up 10x. My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor: Imagine you have to pick a bike to go on a trip. You're travelling on a wel…

Reminds me of something Bruce McKinney said about Visual Basic when I was much younger and beginning to learn about computers in general, I'm paraphrasing here but the gist was "Visual Basic makes 95% of your task easy and the other 5% impossible". Of course Bruce is a hard core programmer so he went on to show you how to do the 5% in VB using some crazy hacks or, better, do it in C/C++ using COM and glue it onto you…

Back in the COM days, we were largely a C++ shop. There were times where our business folks did not quite know what they wanted - so we'd prototype the COM component out in VB. It worked a little too well - for about a quarter of the time, you ended up with something that only had a 10% (or less) performance penalty.

Re: The “No Code” Delusion

#256

Post by cgrealy »

z3t4 wrote: post #245
AnimalMuppet wrote: post #170

Earlier quoted context omitted.

What you need is a speed bike that lets you switch to a mountain bike when you decide you need/want to go off the trail. That is, a "no code" or graphical or whatever whizz-bang tool that lets you drop into C++ or Python or Lisp or whatever when you need to. And to do this, it needs to be better than JNI in Java. It needs to be able to have something better than a gouge-your-eyeballs-out-ugly syntax for interfacing t…

I think the abstraction layers are important, they should not be leaky. You shouldn't have to go up/down the stack. If you can't build what you want with one tool, then choose another tool.

Couldn't disagree more. Unless your job is unbelievably trivial, you should use a range of tools and use the best one available for the task at hand.

Re: The “No Code” Delusion

#257

Post by Rury »

sequoia wrote: post #140

I was once at a company (X) that acquired another company (Y), and Y's main product was a graphical programming tool. Y advertised that their tool could speed application development up 10x. My (nontechnical) manager asked me "why don't you use Y's tool to build the project you're currently working on?" I answered with the following metaphor: Imagine you have to pick a bike to go on a trip. You're travelling on a wel…

Reminds me of a similar situation with my technical manager. He’s very dogmatic in that we should never waste time “re-inventing the wheel” (e.g. there’s already a library/tool out there that does X, don’t waste time remaking it). This makes a lot of sense in many business cases, but not always...

I like using this analogy to demonstrate why:

Say we’re designing a race car, and our race car needs wheels.

“Wait!” says my manager, “don’t waste time designing wheels for our car when we can simply buy these wheels from a vendor and slap it on our car!”

I look at the wheels. “Uh, sure those are wheels, but they’re wheels designed for a shopping cart! I mean sure we could slap these on our racecar but it’s then going to drive like crap!”

If you want a great product, sometimes you’re better off re-inventing the wheel… (and not using a “No Code” solution…)

Re: The “No Code” Delusion

#258

Post by goatlover »

coffee wrote: post #226
honkycat wrote: post #219

My response to "No Code" solutions: If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible. There is no secret programmer cabal where we are holding hostage the REAL tools we use to develop software, and we keep them secret and hidden while we fuck around every day. For someone to develop a…

> If there was a faster and easier way to develop software, we would be doing it. We are already using the easiest to understand tools we can find to develop the best software possible. Not really. As we evolve software development, historically, we've done this through adding new layers of abstraction. Assembly --> C --> Interpreted Code (Java, Ruby, etc...) Why isn't the next layer of abstraction simply what is bei…

Smalltalk was that next level, but for whatever reasons, the programming community never fully embraced that approach, although some modern environments and IDEs come close.

Re: The “No Code” Delusion

#259

Post by slumdev »

fock wrote: post #215
slumdev wrote: post #148

Robotic Process Automation (RPA) is the new "No Code". And it will fail the same way every other "No Code" fad has failed over the years, no matter how successfully McKinsey sells it for the next few years. It will never completely disappear, but there is no future where a BA with an overhyped macro suite replaces the whole of software engineering.

ok, if it is, what the wiki-article tells, we had this with autohotkey 15 years ago. How is the RPA integrating with the data from this processes? Does it rely on accessibility APIs (good luck with that for more specialized software)?

I think the "strength" of RPA is creating GUI-based automations and then laying programming interfaces (web-based or otherwise) on top of them.

It's still hogwash.

Re: The “No Code” Delusion

#260

Post by busterarm »

segmondy wrote: post #95

The "No Code" movement is not a delusion. Most of us in tech are very ego driven and don't think this will happen, the majority is not in tech and want this to happen. It will happen.

I feel like everyone misunderstood what the "No Code" movement is supposed to be about.

It's "No Code is the Best Code". The idea is that the code you should be writing should be things that are the core of what your business does. Those things should be sufficiently hard to replicate. Everything else should be a commoditized product or open source infrastructure that you deploy.

This way you avoid time reinventing the wheel or, much more importantly, making your product something that's easy to commoditize!

I've worked at companies with hundreds of complex Java microservices that essentially replicate built-in functionality provided by NGINX, HAProxy, etc. Literally for no other reason that the people making the decisions know how to write code, but they don't know how to productionize and configure NGINX or HAProxy.

These companies are more than happy to waste hundreds and thousands of man-hours building and maintaining this code that isn't their product versus hiring more competent ops folks to stand up infrastructure or train developers on cross-functional skills.

When the size of your engineering org starts climbing into the hundreds and thousands, NIH Syndrome kicks into high gear. Heck, I'd actually say it starts around 30.

Post reply on HN