The Agriculture Department, like all large departments, has large and varied software needs. It also develops applications for other agencies as a sort of contractor. USDA has adopted a development methodology known as low-code, no-code. At last week’s Executive Leadership Conference of the ACT-IAC group the Federal Drive with Tom Temin caught up with the USDA’s Jerry Hingtgen, federal project lead for software-as-a-service software development.

Interview transcript:

Tom Temin There’s a lot of ways to develop software. You have, at least for now, glommed on to the low-code, no-code technology. Fundamentally, why?

Jerry Hingtgen Well, if you think about it from from an aspect of how do you develop quickly to get away from these long term three to five year IT projects that halfway through that implementation, your requirements change. Or in the case of AI, you have a disruptive technology. No-code, low code, it allows you to quickly change gears without having to go back and recode everything of all that custom coding.

        Join us Nov. 18 for Federal News Network's Industry Exchange Cloud to learn how your agency can deliver services effectively, efficiently and securely in a hybrid, multicloud world. Register today!

Tom Temin Low-code, no-code is really kind of misnamed, isn’t it? It’s no coding, low-coding because code is produced.

Jerry Hingtgen Code is produced, correct. A better way to say it would be configuration over coding.

Tom Temin And who does the configuration? The traditional software developers don’t touch it, or do they?

Jerry Hingtgen No they do, 100% of software developers. In the case of my work at Rural Development and in other work that I’ve done, it is all software developments, whether they’re fed staff, whether they’re contractors, they’re all developers. They have to be able to understand how that configuration will affect the function of that feature functionality that I’m trying to implement.

Tom Temin And when working with low-code, no-code, and we’ll get to the difference between the two. Are you able to do the testing and examination such that, say, if you deploy a module that it will in fact work with what’s already in place, that kind of thing?

Jerry Hingtgen Absolutely, 100%. With Low-code, no-code it’s no different than your standard traditional coding. You still have the ability to scan the code. You still have the ability to review the code you still have. You lose nothing. It’s just a different way to look at how we implement IT solutions.

Tom Temin But there must be some advantages then. Otherwise, just do the traditional coding.

Jerry Hingtgen Sure, there’s a lot of advantages. You heard me talk earlier today about the modularity of how we’re trying to get to that modularity and the sharing and reuse. That’s a huge advantage of low-code, no-code or clicks over configuration. It’s being able to quickly configure versus writing all that custom code that it would be great if I wrote every single piece of code. But in a lot of cases people retire, especially in the federal government. We have a green workforce. And with low-code, no-code, there’s very little tribal knowledge that needs to be passed from one developer to the next. You’re relying on the configuration of of the platform you’re developing on.

        Read more: Workforce

Tom Temin And by the way, what’s the difference between low-code and no-code?

Jerry Hingtgen So low-code, there’s similar but I’ll tell you about what the differences are. No-code is you’re simply doing configurations for the entire platform, the entire application. Low-code is for the most part, it’s similar to no-code, but you do still need to customize. Maybe there’s a report, custom report you want to generate, and you need to be able to do the functions in a better way that you’re not going to get out of the configuration. So there is a balance, again, depending on the requirements.

Tom Temin And what about the output? That is to say there’s a bunch of hidden no-code, low-code vendors out there. Do they all produce the same code? Is it Java, is it COBOL, is it C++, what comes out of it?

Jerry Hingtgen So, again, depending on your platform. With a particular vendor, you’re going to have apex code. Apex, Java they’re not identical, but they’re very similar. And lot of developers in the industry today understand that Java code, that’s what they’ve used for years, that’s what people used for years. Apex code is the same thing. There’s enough commonality that you’re able to go back and forth and understand what that code is doing. Unlike the COBOL programs we hear talk about today, where those people that designed that and programed in that, they’re no longer around.

Tom Temin Sure. And they also had a whole different methodology. You code it right to a set of instructions right there on the hardware, very different nowadays. We are speaking with Jerry Hingtgen, he is the federal project lead software-as-a- service software development lead for the Department of Agriculture. You mentioned governance issues with Low-code, no-code. What are they, and why are they unique to Low-code, no-code.

Jerry Hingtgen Well, they’re not unique. It’s more of a larger problem of governance within the federal government. But really, it’s when we talk governance in the low-code, no-code environment, it’s about that best practices. Each of the platforms have a best practice that this is a way to implement this feature functionality capability that you’re trying to get with. Governance is important, there’s coding standards that are to be implemented. There’s best practices and ways to do things. Governance is very important, whether you’re no-code, low-code or whether you’re 100% custom coding.

Tom Temin And let’s talk about some of the things you’re doing in USDA in this manner with Low-code, no code. What are some of the top line projects you’re pursuing?

        Sign up for our daily newsletter so you never miss a beat on all things federal

Jerry Hingtgen So currently I’m working on a project with FEMA where FEMA has hired USDA to build and manage and run the infrastructure for their Hermit’s Peak/Calf Canyon claims loss program. So we’re doing that and it’s primarily no-code, low-code. There is some custom coding in that. In the past with rural development, it was the congressional announcement management system, where the total amount of code that was in that program was less than 170 lines of code. Everything else was no-code.

Tom Temin Wow, and if you are modernizing an application or adding to an existing enterprise application, how do you know or what’s the methodology for ensuring that the output of the low-code, no-code embodies all of the business rules that really relate to the program rules ultimately?

Jerry Hingtgen Great question, but it really boils down to what are my requirements, Tom? Tell me what your requirements are and I can tell you what the best technical solution is that’s going to fit those requirements.

Tom Temin And you find that having your own people use these tools gets you closer sooner than, say, the integrators or external people because of understanding of the government context.

Jerry Hingtgen It does, and not to say there’s a time and place for solution integrators, but there’s also a time and place where government needs to have expertise in that field of not just low-code, no-code, but any kind of IT software development, where those expert government experts need to have the wherewithal to when a solution integrators proposing potential solution to solve a business problem that we really need that expertise to say yes, this is a good approach. Yes, this matches whether it’s USDA or other federal agency best practices with as follows the platform best practices. It’s very vital.

Tom Temin And final question. Intellectual property of the output of low-code, no-code. Is that the government? And if you develop something and say another third agency could use that 175 lines of code, it’s theirs to use?

Jerry Hingtgen Absolutely. Again, it depends on how the contract is written. But in the case of the work of sharing the code with FDIC, it was in when FDIC initially wrote that contract for that software to be developed, it was written into the contract that they could share it with other agencies. And this also plays right into data rights. Inherently the government has data rights, whether it’s solution integrator develop code, whether it’s no-code, low-code, the government owns the data rights.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.