Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 14-Day Trial for You or Your Team.

Learn More →

Managing Technical Debt

Managing Technical Debt DEVELOPMENT Managing Technical Debt Shortcuts that save money and time today can cost you down the road. Eric Allman In 1992, Ward Cunningham published a report at OOPSLA (Object-oriented Programming, Systems, Languages, and Applications)2 in which he proposed the concept of technical debt. He defines it in terms of immature code: œShipping first-time code is like going into debt.  Technical debt isn ™t limited to first-time code, however. There are many ways and reasons (not all bad) to take on technical debt. Technical debt often results from the tension between engineering œbest practices  and other factors (ship date, cost of tools, and the skills of the engineers that are available, among others). Roughly speaking, technical debt is acquired when engineers take shortcuts that fall short of best practices. This includes sneaking around an abstraction because it is too hard (or impossible) to figure how to œdo it right,  skipping or scrimping on documentation (both in the code and external documentation), using an obscure or incomplete error message because it ™s just too hard to create something more informative, implementing code using a simple but slow algorithm even though they know that a better algorithm will http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png Queue Association for Computing Machinery

Managing Technical Debt

Queue , Volume 10 (3) – Mar 1, 2012

Loading next page...
 
/lp/association-for-computing-machinery/managing-technical-debt-tEmvXM2nmK
Publisher
Association for Computing Machinery
Copyright
Copyright © 2012 by ACM Inc.
ISSN
1542-7730
DOI
10.1145/2168796.2168798
Publisher site
See Article on Publisher Site

Abstract

DEVELOPMENT Managing Technical Debt Shortcuts that save money and time today can cost you down the road. Eric Allman In 1992, Ward Cunningham published a report at OOPSLA (Object-oriented Programming, Systems, Languages, and Applications)2 in which he proposed the concept of technical debt. He defines it in terms of immature code: œShipping first-time code is like going into debt.  Technical debt isn ™t limited to first-time code, however. There are many ways and reasons (not all bad) to take on technical debt. Technical debt often results from the tension between engineering œbest practices  and other factors (ship date, cost of tools, and the skills of the engineers that are available, among others). Roughly speaking, technical debt is acquired when engineers take shortcuts that fall short of best practices. This includes sneaking around an abstraction because it is too hard (or impossible) to figure how to œdo it right,  skipping or scrimping on documentation (both in the code and external documentation), using an obscure or incomplete error message because it ™s just too hard to create something more informative, implementing code using a simple but slow algorithm even though they know that a better algorithm will

Journal

QueueAssociation for Computing Machinery

Published: Mar 1, 2012

There are no references for this article.