Coding Without Code: A Journey in Low-code/No-Code Development

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to another episode of the CTO advisor podcast. We've been talking about getting a no code developer on the line forever. Uh, actually have one with me here in person, Delaney Dalton. Welcome to the show. So this show is mainly for enterprise architects, CTOs, people on the technical side, but you're not working on the technical side of no code. You're, you're acting, working with the platform. What platform are you using? Uh, we are using, I work on the healthcare payer side of, uh, things for insurance and we're using, uh, apply pathways has a platform called Curion, uh, is an authoring platform, uh, that basically builds call tree algorithms.

So we'll get into the details of that in a bit, but in your peer group, both me and you have talked about the concept of low code and no code. Is this a term that many of your peers would use to describe what they do? On our side, no, uh, the clinical authoring team, we don't use the low code, no code title, uh, to describe what we do. We use authoring as a kind of catch all that, uh, what we do on the more technical side of things where they're doing like the development of Curion, they would use the local no code title.

Okay. So what's your background? You've been at this role. I think the pre conversation for about six years now for six years. Yeah. And prior to that, what did you do for, you know, your day-to-day job? Was this also a no-code local job or did you move into it? The six years that I've been doing a low code, no code is the first, uh, role that I've done this. Um, I used to do health insurance. I used to, uh, sell health insurance.

And then I used to do the patient side of health insurance where it was signing people up for different things that are provided to them through their provider. When you saw the advert for this job, what, how was it advertised? It was advertised as they were looking for someone who had some type of, or yeah, background with the clinical side of health insurance, who kind of had some knowledge of how health insurance works and like the inner workings of it. And also some background in, um, just the medical field.

When you took the job, what do you think it was? What I knew it wasn't was customer service. I thought it would be more of like, you know, like billing in a way. It was kind of advertised like that. So like medical coding type of deal. Yeah. But, you know, in the interview, they kind of explain it. Um, when I started, it was from the ground up, it was brand new to the company that I started with. It was a new role, a new aspect of what they were doing in-house.

When you heard that you would be building algorithms, was that intimidating? A little bit. Yeah, it was intimidating. They did give us a sort of a test during the interview. It was more of a, it was kind of like a logic test. They were kind of seeing how you would handle logic. So it was like, if I did this, what's missing here? How would you go about finishing this logic? So it was kind of that. And I was like, oh, okay.

Does it tell me I'm a more logic based person? So I was like, oh, this is easy. I don't get, I didn't get, I was like, I didn't get the complicated. Cause it was kind of posed to you as, oh, we've been really having a hard time finding people to fill this role because people don't get the logic. You know, some people naturally think this way, as you, as you mentioned, and some people just don't get it. Have you found that over the course of six years that people, uh, have turned over, they just don't get the, the, the logic of how computers, uh, interact with humans?

Yeah. I think so far, uh, for our team, we've had some, we not, we've not had many like turnovers, but we have had a few people come and go where they just couldn't get the concept of what we were doing. Um, and then the platform that we were using, it was kind of foreign to them. Um, they couldn't get, you know, like just the simple things. Well, for me, the simple things like, so how do you translate what the nurse and or designer is asking?

How do you translate that into the platform and what tools are you pulling from the platform to use to translate that into something that's working? So they will architect, the nurses will architect, uh, a business logic decision, give you folks kind of the requirements, right? And then what do you do with the requirements once you get the business requirements? So I'll kind of explain our process. So what happens is the provider will have a policy, the healthcare policy, the clinical part of it.

And they'll say, oh, we want to add or change something. So the nurses who are designers will go and they'll, we'll read the policy and then they'll kind of create a blueprint or a layout of what they're asking for, which consists of different questions or just different things within the algorithm that are going to either deny or approve whatever it is that they're looking for on the clinical side, and then it'll come to us, the builders, and we use Curion to translate that into a working algorithm.

So we use, uh, we'll use like the questions, if they should flag, if they should approve straight away, if it should move into different questions, if it should transfer you out into a completely different algorithm. We'll use all of those tools that are built into Curion to do that and turn it into a working exam. So you're getting the application requirements from the nurses, the nurses take that, you then take that requirement from the nurses, build what's essentially the application on this platform Curion, but what I guess what I'm not getting is the interface.

I get how I would do that in Python. I don't get how I would do that in a no code platform. So you're using both built-in tools and words. So for example, is the first question on a exam is a multiple choice question that has six answers. And each of those answers are going to branch off and they're going to go to their own pathways. What you would do is you would pull out, um, there's a built in question. So basically you're just going to a repository and saying, here's a, here's a question or here's a template of what I need to start to a certain state.

You are you part of the process is that you're looking to see if what you're, what you have to add to the algorithm is already built. If it is, is it exactly what you want? Um, one of our main rules is that if something is similar to what you're looking for, but it's off-bar where it will build, we're building it brand new. We're not changing it unless it's being changed across the board. So this is what we call a goading templates in our industry.

You'd have a template for a question. That question might get used across multiple algorithms in your parlance. And if it's off, if you change it for one, uh, platform or algorithm, you got to change it for all of them. So if you need a new one, you need to just create a new one. You need to create a new one mainly because, uh, in the instances that I'm updating something, you don't want to change something that's live that's being used in living, uh, within the workspace.

So if it's be edited, whether it's, you know, grammar wise, whether it's clinical context wise, you need to build something brand new. Yeah. So in the, in the larger developer world, this is called CICD version controlling this, this ability to reuse parts, or even it can be akin to what we call in our industry microservices, right? So this microservice serves several different apps. If you need to change the wording of a microservice, then you need to create a new microservice. I think I get the, your interface part, but how do you deal with, uh, issues of like version control and quality control, like, how do you get from, okay, you've created a algorithm.

How does it get to production? So the way that we deal with version control is to kind of answer that is that we do have a lot of algorithms that are constantly being updated. So for example, I work. Uh, in, uh, the platform, well, the solution MSK solution is one of the more higher, uh, solutions that are like the clinical part of it is constantly moving, the policy is constantly changing. So what happens is, is that if there is something new, if it's a complete total change, we retire the old.

Once we push the new out. So once the build is completely finished building, it goes through a QA process where it's the builder, myself and the designer, we're going over it. We're making sure that it is what they asked for word from word or whatever changes that may be. And then after that is being pushed into our testing workspaces, which we use MSS to test. Um, so we have a different, we have a couple of different stages. There's just basic MSS where it's just the base of the line testing.

Then there's the higher, which is QA. And then there is production, which is used like just before it goes live. There is, um, then there is fit, which is basically live. And that would be, you know, our release deadline is here. This is going to go live for, you know, our end user to use. We want to test it, make sure it's there. And so it kind of gives us an insight to what the end user is actually seeing.

So we're seeing like what it looks like in the, you know, in the, uh, system, how it works, is it working correctly? What we programmed, is it showing correctly? Are our changes showing correctly? Is our things flagging? Is it sending us to where we need to be? So we do our testing process takes about two weeks, depending on the, depending on the release and workload. So is this automated testing or is it manual? So there is an automated testing part.

They use a automated tester called crawler. Well, they'll dump the information in and it'll kind of do an automated testing and say, okay, this looks correct. And then we do a manual testing ourselves where the person who built it, um, we're responsible for our own testing. We test in quality, quality assure that, you know, that the algorithm is working correctly. Is this an all or nothing deployment to production? Meaning once you hit deploy, it's, you know, it's live and the, so if that's the case, what's the rollback, what's the plan if it doesn't, what happens when the, it's not behaving the way you thought it would in product?

So we do have instances of that, especially with MxK solutions where these just, for whatever reason, they don't work. So what we do, it's called a high fix. So if we're in the middle of a release and it's something that can't be pushed in weight, like say if it's a, a grammar issues, a missed period, or there is a missed space, it's like, oh, that's not a big deal. It doesn't change what's clinically needed. Um, usually those things are dropped into releases like, okay, go ahead and fix that.

But if it's something that, oh, it should be approving and it's sending the body, everybody up to referral or sitting, everybody is rejecting everybody. Let's figure out why let's create a hot fix. So we kind of drop everything that you're doing and we, you know, troubleshoot, we go into apply pathways and figure out, is it an issue on our end? Or is this a coding issue? Usually it's a coding issue. We're pretty, they're pretty, um, on us about like, Hey, let's make sure, you know, we go through so many steps before it goes live there, like, you know, these small mistakes and things like that shouldn't be happening.

So it's in general, an IT issue is what we call it. But the hot fixes that you kind of fix it, you get it in. And then we do an hot fix release where we'll say we're aiming for the turnaround to be a day after we find the issue and put it back out live. Does you and your team have a concept of defect tracking where whether, you know, you it's pre production or in production, it's not a, it's not a fix immediate, but it's just a defect and you have to get, get to fixing it the next revision.

Yes. So they do track, um, the changes and fixes. Uh, if things are pulled from releases, we have instances where a customer will say, I really don't want to put this product out right now, but at some point I will, so we'll say, Hey, this is built. This is ready. We're going to push it out to let's say November and we'll revisit it then. And then there are things that come back and they need to be fixed. Like the grammar issues and things like that.

I would say we'll keep a track and say, this is not immediate, but it does need to be fixed. When can we. It's pretty much based off of need. It's a need based thing is when do we have the time? What's the urgency on it? And when can we get it? So from a career perspective, we've done this for six years. Do you have any desire to go into coding or other adjacent functions that you are interested in the proper kind of, and I want to say proper, cause this is coding.

You've talked about all the challenges that we talked about in coding. It's just that your language is this Curion and MSK solutions platform. I do have an interest in, I would like to move into the more, the side of it where they're deciding what goes into Curion and what helps the Arthur to build, because just using the platform, you get to understand and know what works and what doesn't work. And you kind of get, when you're talking to the designers and you're listening to what they want, and then you go and you look in Curion, you're like, I don't know if I can build it this way.

I don't know if I can make it this way, or if we could do something different. Um, one of the things recently, our Curion platform got updated. 0. And one of the things that we had been asking them for is the way that you, when we are creating the call tree, when we pull out a question and we want to say this answer goes to the next question, it was so tedious to have to then pull out an edge line and connect the edge line.

And one of the ideas that I had that they implemented is that the edge line should be built within the question. You just pull it out in this, you know, it's saving you time and that the chart that we're actually building on shouldn't be a stagnant chart where we run out of space because we have huge algorithms that are like 500 questions and then you run out of space and then you have to use another chart and you're trying to keep track of what goes here, what goes here, the chart should be infinite.

And so something like that, they implement it where it's however far you stretch out, you can build and you don't have to worry about doubling charts. So I want to get on the side of taking those ideas and implementing them into Curion so that the Arthur has a better end user, a better end user experience. So there's a bunch of things I'd like to talk to you about as it relates to that, this idea of product management. That's what that's called. You want to get on the product management side, this whole, you know, is there this concept of developer relations where Curion and MSK people come and just help you guys or you folks think through how to approach problems differently.

There's so many options, but you know, we're out of time. This is just a podcast. com. Uh, and if you want to learn more about the future group, future group, Delaney, if there's any, you know, hiring managers out there that want to hire you for product management, how do they get ahold of you? They can get ahold of me, uh, via my social medias on the Twitters. I am at Elaine D that's E-L-A-I-N-D-E-E. Um, I am also that on all other social platforms or, you know, you can email me what you can find on my social medias as well.

All right, Delaney. Thanks a lot for joining the podcast. Thanks.