by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
GCN : January and February 2016
GCN JANUARY/FEBRUARY 2016 • GCN.COM 25 technical debt? tions to tackle challenges in areas such as public health and education.” The effort to balance the funding of older legacy systems against the urgencies of new priorities is part of a discussion IT policymakers are having over how to handle “technical debt.” The term refers to the future cost of fixing problems that were created when software was developed. “If I build a piece of software and I’ve made some mistakes [but] don’t have time to fix them now...I know I have to fix them in the future,” said Bill Curtis, executive director of the Consortium for IT Software Quality. “I’ve created a debt, and we’re going to have to pay that debt back sometime by spending time fixing those prob- lems in the future.” The failure to attend to technical debt has a variety of consequences, from slowing down end-user services to setting up conflicts among devel- opers. A recent report by the General Services Administration’s 18F digital services organization quoted IT ana- lyst Jim Highsmith as saying, “As it gets worse, customers complain about slow delivery, increasing the pressure to take more shortcuts, which increas- es the technical debt, which slows the delivery process, which increases cus- tomer dissatisfaction, in a rapidly spi- raling vicious cycle.” To address technical debt, IT and software managers have begun ex- perimenting with new tactics, such as introducing standards for software quality, using those standards in con- tracts and service agreements, and improving code-scanning tools to spot instances when best practices are not being followed. “Today software standards makers want to use measures they’ve created for software structural quality — such as per- formance efficiency, maintainability and reliability, and secu- rity — as a foundation for estimating the amount of technical debt in a system,” Curtis said. “If we can analyze the code, look for violations of good architectural and coding practices in the code, and [determine] the amount of effort required to fix those, then we can use that as an estimate of the amount of technical debt in the system.” Curtis is also a senior vice president and chief scientist at CAST. The company developed the CAST application that scans code for defects, including those related to language and architectural best practices and security vulnerabilities. The tool can also analyze and report on code that is under development, even in complex programming projects. IT consulting firm Booz Allen Hamilton, which on any given day has 300 software development projects underway for mostly government clients, uses CAST to measure coding practices across its teams. “We really procured it as a process improvement tool,” said Dan Tucker, a principal at Booz Allen Hamilton and leader of the firm’s Systems Delivery Group. “CAST...gave us that ar- chitectural view: So this is how complex your system is, how complex it’s been architected, where there might be risk in how the system is coded.” CAST presents levels of analysis that many open-source tools don’t, Tucker said. For instance, it can identify particularly complex sections of code and show which modules have the most logic run- ning through them and which have generated the most comments from coders. Although the firm has used the tool to analyze its internal projects, it has also received queries from gov- ernment agencies. The Air Force and Navy were interested in using CAST to help gauge the impact of adding a significant number of new users to several legacy systems. Using CAST, the firm concluded that the Navy sys- tem was well developed in the secu- rity arena, but its architectural design revealed “brittleness that could result in some latency if it was scaled up.” The CAST tool’s ability to analyze code at the system level could also make it useful in gauging service- level agreement proposals, said Tucker, who recalled a request for proposals that required responders to meet CAST-based service levels. “We saw one RFP that said, ‘Your first order of business will be to make sure it stays at least with this level,’” he said. “It was almost like a service-level agreement based on their structural code quality score coming out of CAST.” Curtis said the Consortium for IT Software Quality plans to submit a standard for technical debt at an upcoming meeting of the Object Management Group standards consortium. The standard would encompass the structural quality of code or “how well the system is built,” he said. “We’re only concerned with the violations of good quality that you know you have to fix because [they create] debt and you’re going to have to pay for [them] in the future.” “Technical debt is a huge cost,” he added. “If government really wants to improve its efficiency and improve costs with- out sacrificing service, it’s going to be determined by the qual- ity of these systems. And removing technical debt will help make that cheaper and more efficient.” • The failure to attend to technical debt has a variety of consequences, from slowing down end- user services to setting up conflicts among developers. 0216gcn_024-025.indd 25 2/3/16 3:16 PM
March and April 2016