Live data from Hacker News

The “No Code” Delusion

alexhudson.com

221–230 of 334 posts

Re: The “No Code” Delusion

#221

As someone who has been managing Low Code/No Code on a large scale for a major enterprise from before this became buzzword soup, I can categorically state that the benefits are real. HN isn't the intended market here, and that disconnect is shown in the currently leading comment thread which is talking about DevOps deployment. DevOps is way beyond what this space currently targets and is working to achieve. To be cry…

I don't think the intent here was to say that LC/NC isn't "real" but that it has been oversold. At my last company they attempted to implement a project in a low code framework and they eventually had to pull back significantly because the requirements were simply too complex for the framework to handle in a reasonable fashion. The lesson is "use the right tool for the job."

Completely agreed! A key portion of managing these platforms is understanding what should NOT go in them.

Because the products are designed for low or no code development they are inherently limited in what they are capable of doing. This is the obvious trade off for the simplicity of that platforms.

Initial analysis to make sure the platform fits the requirements is very important. Also important is understanding that many projects may start on this platform, grow in functionality over time, and eventually need to go beyond the limitations of the platform. I call these applications "graduates", and you need a method to manage the transition out of Low/No Code platform to something else.

Re: The “No Code” Delusion

#222
post #172
post #39

Earlier quoted context omitted.

The pipe dream is far older than that. Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use. The language was COBOL. Oh, and look, this one still seems to be around: http://www.makeyourownsoftware.com/

> Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use. Of course that prediction seems quaint now, but I posit that the prediction failed because they greatly underestimated the increase in demand of software as much as overestimated the ex…

Yes, given that back then people were typically working in assembler (with frequently changing platforms, to boot) and writing relatively simple data processing applications, the claim is somewhat understandable.

But I think the main thing it failed to take into account is more how hard it is to translate business requirements into complete and unambiguous instructions.

Re: The “No Code” Delusion

#223

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…

> "Visual Basic makes 95% of your task easy and the other 5% impossible".

Think what you will of the readability of Perl, but it's hard to beat its motto: "making easy things easy and hard things possible."

Re: The “No Code” Delusion

#224

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.

RPA just seems crazy... I mean, I see the golden shimmer, but why do so many enterprises refuse to actually, you know, solve the problem? I have, btw, just finished reading “the phoenix project”. Brilliant book! Having lived through pretty much that story a couple of times, the solution is just that simple. Not easy, but simple. Been around a while, at several big companies, I know most of them will do RPA (they are…

There is a competition between RPA and automation by Python ongoing in my workplace. We are low on devs and high on buzzword-susceptible non-technical managers. The argument that it is a lot smarter to hire a few more devs that would add a lot more value to the company, especially given that we have already made significant inroads in 'proper' automation, than pay for a proprietary tool that is essentially an overhyped Selenium browser falls on deaf ears, since learning is hard and klickety klick is simple and easy to outsource. So it goes.

Re: The “No Code” Delusion

#225
post #202

I think those with a programming background take terms like "no code" far too literally. For those who've worked in finance IT, you may know of staff who've build incredibly elaborate models in Excel, and then have come to you when they need something that can't be done in Excel. "No code platforms" will likely work the same way. These platforms provide just enough interactive/dynamic functionality for non-programmer…

IMO, Excel was one of the first 'no code' platforms. The first part of my career was taking Excel solutions and turning them into something that could used corporate wide. It was pretty fun because by the time it got to my team, the requirements were pretty well hammered out.

Re: The “No Code” Delusion

#226

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 being termed as "No Code" today?

Re: The “No Code” Delusion

#227
post #202

I think those with a programming background take terms like "no code" far too literally. For those who've worked in finance IT, you may know of staff who've build incredibly elaborate models in Excel, and then have come to you when they need something that can't be done in Excel. "No code platforms" will likely work the same way. These platforms provide just enough interactive/dynamic functionality for non-programmer…

IMO, Excel was one of the first 'no code' platforms. The first part of my career was taking Excel solutions and turning them into something that could used corporate wide. It was pretty fun because by the time it got to my team, the requirements were pretty well hammered out.

I worked with or around a number of people who had to productize an Excel spreadsheet when the team got a little too big for that to work and everyone was always surprised by how long it takes to recreate all of the functionality they had built up in Excel.

When Oracle bought Sun and got Open Office people as part of the deal, I thought for sure that Larry had some plan for an Excel killer to make it quicker to transition people out of Excel into relational databases.

I kept waiting for the other shoe to drop and it never arrived.

Re: The “No Code” Delusion

#228

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…

Conversely, we have not in 2020 reached the peak of software development. Presumably there are faster and easier ways to develop software that haven’t yet been invented.

Of course, it’s probably more likely that a no-code solution like you’re describing would be the result of decades of iterative development rather than one genius project. Put that way, it seems like we’re heading in the right direction, no?

Re: The “No Code” Delusion

#229
post #213
post #202

I think those with a programming background take terms like "no code" far too literally. For those who've worked in finance IT, you may know of staff who've build incredibly elaborate models in Excel, and then have come to you when they need something that can't be done in Excel. "No code platforms" will likely work the same way. These platforms provide just enough interactive/dynamic functionality for non-programmer…

I have spent 5 years on and off in the no code space and IMHO you're almost spot on. Almost all standard enterprise platforms are non complex and can be delivered in no code solutions, requiring maybe 5pc as real code. Failing to acknowledge this is why IT organisations in large enterprises are typically sidelined by shadow IT teams, who often deliver great solutions in Excel and Oracle Apex.

I've spent 2 years in a fairly large bank, and I heavily disagree. We have tons of procedures and edge cases that are subtlely unique.

Our problem is purely one of speed. When there's 3 quarters and 5 org layers between you and the developer, you are much more likely to just grab a tool you have access to and get to work.

Post reply on HN