software development - Federal News Network

Listen Live

USDA

Workforce

What's behind a software development strategy at the Agriculture Department

"With Low-code, no-code it's no different than your standard traditional coding. You still have the ability to scan the code, said Jerry Hingtgen.

Cybersecurity

Cyber Leaders Exchange: Army, SSA and USCIS cyber chiefs on securing software through automation

Army

Army Contracting Command driving move to agile software

Federal Insights

Software development and continuous testing are the wind beneath the F-35's wings
Insight by Synack

Federal Insights

State Department employing continuous automated testing in software development
Sponsored by Synack

IT Modernization

Coast Guard building software development foundation
Sponsored by LaunchDarkly

Technology

NASA's software development gets complex
Sponsored by Rancher Government Solutions

IT Modernization

Tackling the Air Force computer problem one PC at a time

Kathleen Hicks

Defense News

Pentagon has plan to fix its software development woes

Head shot of Janek Claus

Federal Tech Talk

Rapid software development in the federal government

In this Aug. 5, 2019, photo released by the U.S. Air Force, an F-35 fighter jet pilot and crew prepare for a mission at Al-Dhafra Air Base in the United Arab Emirates. The Trump administration has formally notified Congress that it plans to sell 50 advanced F-35 fighter jets to the United Arab Emirates as part of a broader arms deal worth more than $23 billion. (Staff Sgt. Chris Thornbury/U.S. Air Force via AP)

Air Force

Smarter software could help Air Force cut fuel bills by a million gallons per week

Head shot of Nicolas Chaillan

Federal Tech Talk

A creative approach to improving software for the Air Force

Acquisition and Sustainment Undersecretary Ellen Lord at a Defense Writers Group event in Washington D.C.

Acquisition

Pentagon teeing up nine programs to test new 'color of money' for software development

In this Wednesday, Nov. 4, 2015 photo, Kiah clears a hurdle on an obstacle course at K9 school in Stone Ridge, N.Y. Kiah, a two-and-a-half year old pit bull, will soon join the Poughkeepsie Police Department as a crime-fighting, drug-sniffing police dog, a move that advocates of the breed say will counter the stereotypical image of the dog as a dangerous breed beloved by criminals. (AP Photo/Mike Groll)

Tom Temin Commentary

Artificial intelligence: The pit bull of computing

Michael Kratsios

Federal Newscast

Trump names pick for US chief technology officer

Amelia Friedman

What's Working in Washington

Why small business owners and investors should get involved

brisbonkatrina_official_TSA

Federal Drive

TSA wants to move FAST on software acquisition

Cloud computing and technology network connection concept, Businessman hand holding icon cloud server transfer data device

All News

Insight by General Dynamics Information Technology Using application services to enhance government customer experience

Nick Guertin, senior software systems engineer at the Software Engineering Institute at Carnegie Mellon University

All News

Open systems evolving to improve DoD buying power

United States Military Academy cadet Dylan Hyde watches data on a computer at the Cyber Research Center at the United States Military Academy in West Point, N.Y., Wednesday, April 9, 2014. The West Point cadets are fending off cyber attacks this week as part of an exercise involving all the service academies. The annual Cyber Defense Exercise requires teams from the five service academies to create computer networks that can withstand attacks from the National Security Agency and the Department of Defense. (AP Photo/Mel Evans)

Acquisition

Innovation board has a dozen ideas to help fix DoD's software acquisition woes

[hbidcpodcast podcastid='5214098']

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 <b data-stringify-type="bold"><i data-stringify-type="italic"><a class="c-link" href="https://federalnewsnetwork.com/category/temin/tom-temin-federal-drive/" target="_blank" rel="noopener" data-stringify-link="https://federalnewsnetwork.com/category/temin/tom-temin-federal-drive/" data-sk="tooltip_parent">the Federal Drive with Tom Temin</a></i></b> caught up with the USDA's Jerry Hingtgen, federal project lead for software-as-a-service software development.

<em>Interview transcript:</em>
<blockquote><strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>Low-code, no-code is really kind of misnamed, isn't it? It's no coding, low-coding because code is produced.

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

<strong>Tom Temin </strong>And who does the configuration? The traditional software developers don't touch it, or do they?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

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

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>And by the way, what's the difference between low-code and no-code?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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.

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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.

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.</blockquote>

Federal Tech Talk

The modern way to develop safe code

[hbidcpodcast podcastid='5214098']

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 <b data-stringify-type="bold"><i data-stringify-type="italic"><a class="c-link" href="https://federalnewsnetwork.com/category/temin/tom-temin-federal-drive/" target="_blank" rel="noopener" data-stringify-link="https://federalnewsnetwork.com/category/temin/tom-temin-federal-drive/" data-sk="tooltip_parent">the Federal Drive with Tom Temin</a></i></b> caught up with the USDA's Jerry Hingtgen, federal project lead for software-as-a-service software development.

<em>Interview transcript:</em>
<blockquote><strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>Low-code, no-code is really kind of misnamed, isn't it? It's no coding, low-coding because code is produced.

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

<strong>Tom Temin </strong>And who does the configuration? The traditional software developers don't touch it, or do they?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

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

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>And by the way, what's the difference between low-code and no-code?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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.

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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.

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.</blockquote>

Federal Tech Talk

Oracle: Modern cloud for a modern government

[hbidcpodcast podcastid='5214098']

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 <b data-stringify-type="bold"><i data-stringify-type="italic"><a class="c-link" href="https://federalnewsnetwork.com/category/temin/tom-temin-federal-drive/" target="_blank" rel="noopener" data-stringify-link="https://federalnewsnetwork.com/category/temin/tom-temin-federal-drive/" data-sk="tooltip_parent">the Federal Drive with Tom Temin</a></i></b> caught up with the USDA's Jerry Hingtgen, federal project lead for software-as-a-service software development.

<em>Interview transcript:</em>
<blockquote><strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>Low-code, no-code is really kind of misnamed, isn't it? It's no coding, low-coding because code is produced.

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

<strong>Tom Temin </strong>And who does the configuration? The traditional software developers don't touch it, or do they?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

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

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>And by the way, what's the difference between low-code and no-code?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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.

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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.

<strong>Jerry Hingtgen </strong>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.

<strong>Tom Temin </strong>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?

<strong>Jerry Hingtgen </strong>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.</blockquote>

Federal Tech Talk

DevOps & identity management