rashbre central: Waiting for the phrase Technical Debt to be in a sentence with Horizon.

Tuesday 9 January 2024

Waiting for the phrase Technical Debt to be in a sentence with Horizon.


I'd add project is overrunning and the commercial folk are getting agitated about the contract.

Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. 

In other words, it’s the result of prioritizing speedy delivery over perfect code. 

aka 'shipping bugs' 

 If you’ve been in the software industry for any period of time, chances are you’ve heard the term “technical debt”. Also known as design debt or code debt, the phrase (or more accurately, the metaphor) is widely used in the technology space. It is referred to as a catchall that covers everything from bugs to legacy code, to missing documentation. But what exactly is technical debt anyway? And why do we call it that? 

 Technical debt is a phrase originally coined by software developer, Ward Cunningham, who in addition to being one of 17 authors of the Agile Manifesto, is also credited with inventing the wiki. He first used the metaphor to explain to non-technical stakeholders at WyCash why resources needed to be budgeted for refactoring. 

 He didn’t realize at the time, but he had coined a new buzzword in the software community. Later, it would become the subject of countless academic studies, debates, and panel discussions. 

 Years later, Cunningham described how he initially came up with the technical debt metaphor: 

 “With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.”


No comments: