Technical debt can develop into a serious problem if not properly addressed.
It's not exactly the height of philosophical observation to point out that choosing the quickest solution to a problem in the hope of short-term gains (while ignoring long-term implications) is almost always a flawed strategy. But that doesn't make it any less true! The phenomenon known as "technical debt," which has developed into a significant concern among programmers and IT professionals - not to mention the chief technology officers and other company leaders who oversee their work - stands out as a major example of the frustrating truism described above.
Those who spend most of their time in the coding trenches are the ones who deal with technical debt most directly, of course. If caught early, resolving it won't be too much trouble for a group of skilled programmers (and other IT staffers, helping out in support roles). But if the issue is allowed to grow unimpeded and develop into a problem of any serious magnitude, it can start affecting the course of daily operations, which in turn does damage to productivity, revenue and even the company's reputation within its industry.
Appian takes no small pride in anticipating the potential problems of the future and working toward solutions to address them today. Technical debt has by no means escaped our radar. Here, we'll take a deep dive into the concept of technical debt, how it gestates within an organization's core of data and how custom business process management software developed with the Appian platform can be part of the valuable counterattacks that keep organizations running smoothly for the benefit of all involved.
A beginner's guide to technical debt
According to Techopedia, veteran programmer and tech consultant Ward Cunningham (arguably best known for creating WikiWikiWeb, a user-editable website built on the same concepts that still drive Wikipedia) discovered the issue of technical debt. Hecoined the term when explaining it formally in 1992 at that year'sOOPSLA(Object-Oriented Programming, Systems, Languages and Applications) conference:
"Shipping first-time code is like going into debt," Cunningham stated. "A little debt speeds development so long as it is paid back promptly ... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation."
Technical debt serves as a sterling example of how flawed results-now, consequences-later strategies can be. Appian's second installment of our whitepaperseries "The Future of Work," released earlier this fall, boils it down to "choosing any easy solution now over the right solution."
Consider it this way: Any application, network or platform that is quick, easy and cheap to install but will require correctives later ultimately costs much more than its early performance, which will be competent and maybe even exemplary, suggests: That honeymoon will be over quickly, and in fairly little time programmers could be spending hours tied up in repair. Meanwhile, putting in a great deal of work and time to implement a system that functions more robustly and requires little to no costly retooling in the future will benefit the bottom line much more substantively as time goes by.
Identifying the common causes
In Cunningham's original explanation of technical debt, he points out that the phenomenon isn't automatically a bad thing - it can be value-neutral, a natural consequence of the development process. It can also be negative but unavoidable, according to DagLiodden, co-founder and CTO of the advertising tech provider Tapad. In an interview for tech venture capital firmFirstMark'sHacker Noon blog, unavoidable (or, in his words, "deliberate") technical debt occurs when a product suddenly has to be rushed to marketat the behest of C-level leadership, or perhaps in reaction to a competitor's unexpected early system launch, which the entire organization will want to answer. While suboptimal, this type of technical debt probably won't do any long-lasting damage.
Trouble begins brewing when technical debt arises as a result of quality declines, whether occurring accidentally or organically through a lack of well-established best practices. As Agile Alliance pointed out, improperly written code, bugs, errors in platform architecture, test coverage and duplication are just a few of the bad practices that can create this sort of debt, and every one of them (or any combination thereof) can have disastrous consequences for the productivity - and, eventually, the profitability - of any organization.
Last but certainly not least is what FirstMark refers to as "bit rot tech debt:" This is the gradual entropy of a platform's performance due to wear and tear that's brought upon the system through a multiplicity of small changes. In and of themselves, these alterations may not be problematic (and some, most likely, will have been necessary), but they become dangerous when implemented by a number of different programmers or IT personnel who aren't all operating according to the same plans or principles, or don't fully understand the original design. All things considered, this type of technical debt may be the most detrimental of all.
Fighting - and winning - the battle against technical debt
No matter the specific origin of this particular deficiency, the potential adverse consequences of it can't be understated: By conducting surveys of 500 C-level IT leaders on behalf of Appian for our aforementioned whitepaper, IDG identified that 40 percent of these companies' IT development time involved addressing problems caused by technical debt. It doesn't take a tech expert to understand how much lost productivity that percentage can amount to.
So how do you start the fight against technical debt and strike winning blows?IT leaders' answers to what caused this issue most often point the way toward potential solutions:
- In the U.S., IT being siloed away from the rest of organizational operations was the biggest debt cause, so it naturally follows that IT and all other departments should regularly communicate to mitigate such separation.
- Respondents from businesses in Europe and the Middle East, meanwhile, said poor documentation requirements and project briefs led to more technical debt than anything else. Preemptive labor to ensure briefs and requirements are more thorough and don't lead to mistakes by programmers and other IT personnel will help reduce the negative consequences of this factor.
- Simplification, wherever possible, will also be a boon to the development process and a counterattack on technical debt. By using enterprise-scale low-code operations conducted through adept use of the Appian application delivery platform, organizations can create customer-facing and internal apps at a faster pace and with great efficacy while not accruing gargantuan tech debts.
To learn more: contact us today or start a free trial!
