Automating The Government Workforce—The Training Debt Problem
The views expressed are those of the author and do not necessarily reflect the views of ASPA as an organization.
By Bill Brantley
November 12, 2019
As governments continue their digital transformations, you may hear more about technical debt. Technical debt, as defined by the noted software development expert Martin Fowler, is the, “Long-term consequences of, ‘Quick and dirty,’ program changes made to meet deadlines instead of coding, ‘The better design.’” The most famous example of technical debt is the Y2K Date Change problem. The early COBOL programs could only handle the last two digits of a year. This quick-fix was fine at the time because the COBOL programs were being written in the 1960s, and it seemed unlikely that governments would still use COBOL by the time 2000 came around.
Thus, fixing COBOL to handle four-digit years was pushed back to the 1970s. Then, the 1980s. Not until 1998 did the United States government begin a concentrated effort to deal with the Y2K Date Change Issue. Private industry began dealing with the problem, but it wasn’t until the mid-90s that the problem took on urgency, all because of the assumption that COBOL software would have been phased out or fixed long before 2000.
My first job in the United States federal government was working on the General Services Administration’s Y2K Task Force. I helped with outreach to the American Indian communities and small communities through the American Library Association. I learned the importance of a clear and compelling message that explained in simple terms the necessity of preparing for a potential technology threat. The most persistent question from the public is why the federal government and companies didn’t act sooner.
The Three Types of Technical Debt
Dag Liodden, co-founder and Chief Technical Officer of the adtech company Tapad, argues that technical debt is like financial debt. Properly managed, financial debt helps companies grow and reach their strategic goals effectively. Technical debt can also help organizations achieve their goals successfully. The key is to determine the technical debt you have.
There is deliberate technical debt in which the development team programs the, “Wrong way,” to quickly deliver a product. The idea is to buy time now and pay it back later. Don’t buy too much time and risk delaying future product releases.
Accidental or outdated design is the second technical debt. Like the Y2K Data Change problem, designing the system to only work with two-digit years was a quick way to speed up processing time. And, like a credit card bill, ignoring the payment requests only made the final problem fix much more expensive and riskier.
The third technical debt is known as bit rot tech debt. Despite the strange name, you encounter this technical debt when you have a process that started as a simple system. However, as small changes are made to the simple system, the process grows into an extensive, unwieldy process that requires more time and often produces contradictory decisions.
Curing the Three Types of Technical Debt
For all three types of technical debt, the best way to manage them is to keep monitoring the debt and step in early when problems arise. Like managing financial debt, there should be continual reviews on the size of the technical debt to avoid taking on more debt than the organization has the time and the resources to handle effectively. Governments are addressing the issues from technical debt as they work toward digital transformation. However, governments are missing another type of debt that is just as important—if not more critical—than technical debt.
The Looming Crisis of Training Debt in Government
A quick Google search of, “Training debt,” will bring up pages about the student loan debt crisis. That is not what I am referring to here. I operationally define training debt as failing to prepare a workforce for the new workplace technologies. For example, I once supervised a team in Human Resources Information Systems (HRIS) that worked with a COBOL mainframe (in 2015 and still going strong) to produce strategic workforce planning results.
The team was great and very good at what they did. The issue was that we inherited an Access database that would take text-file downloads from the mainframe and then create queries to build a report. We also used Excel to perform calculations. The three team members had only a rudimentary understanding of Excel and could only make simple modifications to the Access queries. Reporting was slow, and my team was continually working overtime.
My solution was to put my team through three days of intense training in Excel and Access. That required me taking over all the department’s work while my staff was busy training. I worked 65 out of 72 hours, but the training paid off as my team became quicker and more efficient in doing their work.
Government workers are being called on to become more proficient with the new artificial-intelligence-powered digital tools. However, as a government training and development professional, I am concerned that governments are accumulating training debt due to outmoded training methods and technologies. Governments need to pay as much attention to their training debts as they do to their technical debts.
Author: Bill Brantley teaches at the University of Louisville. He also works as a Federal employee for the U.S. Patent and Trademark Office. All opinions are his own and do not reflect the views of his employers. You can reach him at http://billbrantley.com.
(1 votes, average: 5.00 out of 5)
Loading...
Automating The Government Workforce—The Training Debt Problem
The views expressed are those of the author and do not necessarily reflect the views of ASPA as an organization.
By Bill Brantley
November 12, 2019
As governments continue their digital transformations, you may hear more about technical debt. Technical debt, as defined by the noted software development expert Martin Fowler, is the, “Long-term consequences of, ‘Quick and dirty,’ program changes made to meet deadlines instead of coding, ‘The better design.’” The most famous example of technical debt is the Y2K Date Change problem. The early COBOL programs could only handle the last two digits of a year. This quick-fix was fine at the time because the COBOL programs were being written in the 1960s, and it seemed unlikely that governments would still use COBOL by the time 2000 came around.
Thus, fixing COBOL to handle four-digit years was pushed back to the 1970s. Then, the 1980s. Not until 1998 did the United States government begin a concentrated effort to deal with the Y2K Date Change Issue. Private industry began dealing with the problem, but it wasn’t until the mid-90s that the problem took on urgency, all because of the assumption that COBOL software would have been phased out or fixed long before 2000.
My first job in the United States federal government was working on the General Services Administration’s Y2K Task Force. I helped with outreach to the American Indian communities and small communities through the American Library Association. I learned the importance of a clear and compelling message that explained in simple terms the necessity of preparing for a potential technology threat. The most persistent question from the public is why the federal government and companies didn’t act sooner.
The Three Types of Technical Debt
Dag Liodden, co-founder and Chief Technical Officer of the adtech company Tapad, argues that technical debt is like financial debt. Properly managed, financial debt helps companies grow and reach their strategic goals effectively. Technical debt can also help organizations achieve their goals successfully. The key is to determine the technical debt you have.
There is deliberate technical debt in which the development team programs the, “Wrong way,” to quickly deliver a product. The idea is to buy time now and pay it back later. Don’t buy too much time and risk delaying future product releases.
Accidental or outdated design is the second technical debt. Like the Y2K Data Change problem, designing the system to only work with two-digit years was a quick way to speed up processing time. And, like a credit card bill, ignoring the payment requests only made the final problem fix much more expensive and riskier.
The third technical debt is known as bit rot tech debt. Despite the strange name, you encounter this technical debt when you have a process that started as a simple system. However, as small changes are made to the simple system, the process grows into an extensive, unwieldy process that requires more time and often produces contradictory decisions.
Curing the Three Types of Technical Debt
For all three types of technical debt, the best way to manage them is to keep monitoring the debt and step in early when problems arise. Like managing financial debt, there should be continual reviews on the size of the technical debt to avoid taking on more debt than the organization has the time and the resources to handle effectively. Governments are addressing the issues from technical debt as they work toward digital transformation. However, governments are missing another type of debt that is just as important—if not more critical—than technical debt.
The Looming Crisis of Training Debt in Government
A quick Google search of, “Training debt,” will bring up pages about the student loan debt crisis. That is not what I am referring to here. I operationally define training debt as failing to prepare a workforce for the new workplace technologies. For example, I once supervised a team in Human Resources Information Systems (HRIS) that worked with a COBOL mainframe (in 2015 and still going strong) to produce strategic workforce planning results.
The team was great and very good at what they did. The issue was that we inherited an Access database that would take text-file downloads from the mainframe and then create queries to build a report. We also used Excel to perform calculations. The three team members had only a rudimentary understanding of Excel and could only make simple modifications to the Access queries. Reporting was slow, and my team was continually working overtime.
My solution was to put my team through three days of intense training in Excel and Access. That required me taking over all the department’s work while my staff was busy training. I worked 65 out of 72 hours, but the training paid off as my team became quicker and more efficient in doing their work.
Government workers are being called on to become more proficient with the new artificial-intelligence-powered digital tools. However, as a government training and development professional, I am concerned that governments are accumulating training debt due to outmoded training methods and technologies. Governments need to pay as much attention to their training debts as they do to their technical debts.
Author: Bill Brantley teaches at the University of Louisville. He also works as a Federal employee for the U.S. Patent and Trademark Office. All opinions are his own and do not reflect the views of his employers. You can reach him at http://billbrantley.com.
Follow Us!