Demystifying Low-Code/No-Code Fallacies – Shiva Nathan, Onymos

This is Textron tv. Hey guys, thanks for the throw. We're here with Shiva Nathan, who is CEO for a, and we're talking about low code, no code, what's real and what's not.

Shiva, welcome the show. Thanks Michael. Thanks for having me on the show.

Appreciate that. So if we are to believe everything that is hyped about low code and no code, it is gonna solve all our issues. Citizen developers will write code magically and all this backlog of applications that we've been talking about for developing for years, it's just gonna magically disappear and yet nothing seems to be moving quite as quickly as we imagined.

So, Shiva, what's going on? Uh, it was low-code. No-code was ably.

The next big thing that's gonna solve world hunger and world peace at the same time, l let's make, uh, citizen developers become um, the extremely productive. What people didn't realize was what is a use case that low-code no can, can solve and what it cannot solve? I think there was blind faith in the fact that oh, it's wanna solve everything.

Um, I think people did not go with going with their eyes open. There is a niche use case where low-code, no-code can actually solve, which are non-mission critical applications that uh, you want to turn up and then do an MVP on it and stuff like that. So that low-code no-code can solve.

If you are really wanting to develop mission critical applications, professional code or pro code is the way to go. It seems to me that most of the time the folks using these low-code no-code tools are actually professional developers that are just trying to do something quickly. That to your point, may not be mission critical.

So, um, ultimately are we seeing this citizen developer emerge or is that more wishful thinking? Um, even for people that are professional developers, um, using pro code, no-code, uh, low-code, no-code, sorry, low-code, no-code. They need to know when they have to call it quits.

If you are a professional developer trying to do an MVP using low-code, no-code, great but do not try, like you build a bicycle, don't try to take like a semi-truck full of uh, truckload of data on top of it. Um, that is a problem. So what happens is that you start with like a small snowball with low-code, no code.

The MVP is good. Your management team likes it and then the management team goes there, oh, add one more thing and add one more thing. Add one more thing, and then you break the proverbial camels back essentially, right?

So you need to know going in, Hey, I can only go so far in my bicycle, which is the low-code, no-code. And if I have to do anything more, I have to stop, get out the bicycle, go back to the starting block, bring myself a semi-truck, which is professional code and then haul the wave to it. So that is a problem.

People do not know when to stop. There's also a lot of talk about generative AI becoming the new user interface for building low-code, no-code applications. The idea is that I will just use a natural language interface to type in what I want.

Is that feasible, realistic? What do you think is gonna play out here Currently? Uh, people that don't really know the details of generative AI think that that's the next, uh, vitamin that they need to take, uh, that will stop aging and make them look for our young, um, generative ai.

Again, like low-code, no-code. The current state of generative ai, I don't wanna say something that's gonna count me in 30 years. The current state of generative AI is good for certain niche use cases.

Again, there are like maybe six, seven commercial use cases that you can use for including like first level support, making your junior developers not harass your senior developers for how to fix this problem and things like that and improving the overall developer productivity. But can generative a generate that professional code for you completely that you can actually develop a mission critical application not in the state that it is in currently in 2023. So that's not gonna happen at least for the next five years in my opinion.

So have you seen any kinda decline in the backlog of the applications requiring professional code? 'cause it seems like, you know, whether it's procedural code or whatever it is, that backlog is still as high if not bigger than ever. Yes.

Unfortunately low code no code contributes to a huge technical debt. Uh, that actually hurts an enterprise development team a lot more than they can even imagine. So what happens is, uh, like I've talked to a lot of, um, CDOs and CEOs that said, oh, I started, I wanted to empower my non-developers to go develop quick things to I trade and do an MVP or my junior developers to create MVP using low code no code before they had really real estate.

Going back to my previous answer, it snowballed that they had one more thing. One more thing and one more thing to it. That now they actually have semi mission critical applications depending on this low-code, no-code application.

That one fine day when the canvas back breaks, they actually bring all of this to the professional developers and say, oh, fix it for me. The professional developers bandaid it. But then the problem is that you have so much technical debt.

It's like you have gone on a bicycle in the middle of a desert and got stuck without water and everything else and now you are calling the professional developers to come and chopper you out. And that essentially is, there's technical debt. You didn't plan for the trip, you didn't, you went on a bicycle without any preparation using low code, no code.

You're stuck in the middle of a desert. You want to incur the company a lot more cost by getting professional developers to come and take you out of that mess that you carried yourself to be in. That's a problem.

So to summarize, low-code, no-code technical debt over time unless you put a stop to it and say this is all the features I provide. Anything more, I'm gonna start from scratch and it's not going to, uh, reduce the technical debt. In fact, it don't actually, it's a ticking time bomb.

It's gonna burst and give you a lot more technical debt sometime in the future. What's the impact of all this on DevOps teams? 'cause it seems like, uh, in theory a lot more code should be moving through the pipelines, but a lot of the times I feel like the low code no code moves through some alternative mechanism that creates more headaches down the road as well as you kind of just alluded to.

Yes. Um, the DevOps, uh, the take an enterprise um, development team and then they've finally selected no low code or a no-code tool and say, oh with a big fan for we are going to empower developers and non-developers to go use this thing. The DevOps team is now like, you know, being in front of a tsunami where every person that can drag a few widgets or right on few lines of uh, core, he is now telling the DevOps, Hey, I build this shiny new thing that my vice president loves it because it just did this one trick.

Really well go push it into production. The DevOps team is under a tsunami know, Hey, what are the security implications? Have we actually gone through robustness?

What's the scalability of this thing? It was great when the vice president used it to demo something, but can it actually with the withhold sort a hundred developers on it or hundred people using it and the DevOps team is like scratching the head, but because it's got like manager, no tons a shiny thing. Uh, they said, oh, I buy dad, I bicycled the block.

And then you tell them, oh go onto the desert now go into the desert. Bicycling, right? And the DevOps team because of management pressure and time pressure and the development team is busy with a lot of other things, they go, oh, this is a shiny new thing, let's actually go do it.

So they go do all this stuff and then the DevOps team now have to deal with when the technical debt comes back to catch up. That's one problem. It also exposes security issues, vulnerabilities, scalability problems and all this other stuff that now the development DevOps team have to worry about.

The call would come in when there are a hundred developers on the low-code, no-code application. When things start to fail a thousand uh, users or whatever when things start to fail is a DevOps team that's holding the bag because it worked great in the demo with one user. And to your point about security, we're struggling to get the professional developers to appreciate security.

What are my odds of getting citizen developers to understand what the security issues of the day are? Yeah. Um, I'll go with another analogy.

Um, imagine, uh, human surgery getting in. All of us can go operate on human beings. Imagine the kind of problem that will uh, happen when you let citizen human beings go do surgeries.

Oh, the simple surgeries like, uh, wisdom teeth and stuff. I can empower you to do that. Um, it's almost like what the residents go through, right?

Medical residents are almost like low code, no code in some sense that they have limited capabilities, but you cannot let 'em go beyond a certain thing. Can they stitch up a bruise? Yeah, they can, can they do minimal things?

Yes they can. But can you let them free to do heart surgery and brain surgery and stuff? No, you cannot.

That's why professional developers come in. Um, that's the same thing with uh, um, DevOps problem. That's the same thing with scalability.

Problem and security is the same thing, right? Security requires a lot more thinking in terms of what are all the implications of security, uh, in the big enterprise when you have state and non-state actors attacking your application, do you think like a citizen developer that's using this low-code? No-code tool will have the to know what are the security implications when you have another country or like a hugely funded actor trying to attack your systems.

That's what requires an architect and a professional developers and pro code in some sense to deal with One of the compliance implications of all that. 'cause as far as I can tell, the regulations are getting more stringent as we go along. So is that getting harder for a citizen developer to follow?

I mean I look at some of those documents and they just make my i's cross. Yeah. So, um, the CSOs of the world, the good CSOs of the world are uh, worried about this.

And the reason is this, you build an MVP or you build a project that gets a little momentum and uh, you expose that project to your customers or your customer's customers. And let's say there's a compliance issue. Now who's holding the back on that compliance issue?

This was supposed to be like a very small MVP project or a project that was done, uh, with a small scope in mind. No, suddenly this project exposed to your data or your customer's data to or this project actually created, uh, a compliance issue for the company in terms of financial reporting or in terms of, uh, security or PHI or PII information or who's holding the bag on this. Um, so that's why I go back to saying you have to know what you're putting on top of your low-code.

No-code, low-code, no-code is amazing when it comes to developing non-mission critical applications. And to take a step back if you're engineering later and think how many consequential applications are out there does developed on low-code, no-code. Has there been any application that's shared the stage with Tim Cook when uh, he demos the next set of mobile applications?

Look up your own phone or look up your own web applications that you use on a day-to-day basis. Uh, you use Uber, use it build using low-code, no-code, you use Salesforce. Is it using low code no code you use whatever application that you use?

Go back and think as a technology leader and as a ciso, how many of them are built using low code no code And therein lies your answer issue. So what is your best advice? Is there a set of best practices for using low-code?

No-code tools? 'cause there are certain use cases at least where they might lend themselves to some sort of solution. But how do you know when to do what?

Begin with the end in mind. I'm not the first person that said this and I'm not gonna be the last person that says this. So you need to start thinking about what is the end for me to do this.

So you do that with uh, uh, everything else that you use in your life. So when you are buying a bicycle for your child, you know how many years this child thing is gonna be used when you buy a mattress? You know how many years this mattress is gonna be used?

Uh, when you use, when you do a development project? Think how long is this going to be used? Start with the end and roll back.

Okay, the low-code, no-code is great. It can arm a citizen developers to build this MVP to showcase and see and even do some small customer markets research to find out whether this actually idea has legs and so on. But don't make that your mission critical application without knowing the ramifications for it.

When you start to add one feature after the next feature, with the next feature, stop and think in terms of am I overloading the underlying infrastructure of low-code, no-code beyond what it was conceived for. Um, you go to a low-code, no-code vendor and tell them, Hey, can I build the next shiny mission critical thing on them? They wanna say yes because they want to sell.

But you uh, as a technology leader that you have to evaluate for yourself is that the be all and end all use case that can go on the low-code, no-code. So if you begin with the end in mind no already saying that this is gonna only have uh, internal users, never intentional users and this is never gonna touch PII even on internal users, you've never gonna touch PHI on internal users. You lay those safeguards right at the beginning and every time you are a feature, you go back to what you wrote initially.

You go back to looking at saying, can my 21 years old child now write this cycle that I bought, uh, when he was five, when he or she was five years old? And you'll go, no, I, when I bought the bicycle for my five year old, I said this bicycle is gonna be there for only next five years. Do we need to have a realistic conversation with business leaders then?

'cause they're the ones that seem to get enamored of this whole thing. And maybe that's part of the conversation is there's just a disconnect between what the IT people know will work and what business leaders seem to believe in. I think we are turning the corner there, Mike.

So I think we are turning the corner where more of the compliance problems that are in the, in industry right now, more of the, uh, security issues that are industry right now are already opened up the ice of the c-suite, uh, to know what tools they can use and what tools they cannot use, at least in the tech sector and the industries that uh, um, are predominantly tech focused and tech related. Are there some industries that are kind of like laggards in tech that are now just catching up to this and maybe outside of the country, outside of the us Are there some geographies where they're catching up to the tech and they are living what the US market lived through 10, 15 years back of thinking that the low-code, no-code is just gonna solve everything? Yes, the answer is yes, but at least in the us the savvy people, the savvy enterprises, the savvy, uh, technologies have caught up to the fact that, hey, I know the limitations.

I know that it is not, it didn't solve the biggest problems of development and technical debt and security issues and vulnerable issues and compliance issues. None of the low-code, no-code tools have solved all of them. And the real, I can say that with confidence because none of the consequential applications are built on low-code, no code today.

Alright. Um, so that's your answer right there. All right folks.

There's no magic bullets out there and there's no substitute for doing the work in the first place. So act accordingly. Hey Sheva, thanks for being on the show.

Thanks. Thanks for your time, Michael. Appreciate And back to the studio.