{"id":997,"date":"2016-11-16T13:33:57","date_gmt":"2016-11-16T18:33:57","guid":{"rendered":"http:\/\/www.smbitjournal.com\/?p=997"},"modified":"2017-02-19T05:03:03","modified_gmt":"2017-02-19T10:03:03","slug":"understanding-technical-debt","status":"publish","type":"post","link":"https:\/\/smbitjournal.com\/2016\/11\/understanding-technical-debt\/","title":{"rendered":"Understanding Technical Debt"},"content":{"rendered":"

From Wikipedia: “Technical debt<\/b><\/a> (also known as design debt<\/b> or code debt<\/b>) is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”.<\/p>\n

Technical debt can be compared to monetary debt<\/a>. If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Unaddressed technical debt increases software entropy<\/a>. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward. On the other hand, some experts claim that the “technical debt” metaphor tends to minimize the impact, which results in insufficient prioritization of the necessary work to correct it.”<\/p>\n

The concept of technical debt comes from the software engineering world, but it applies to the world of IT and business infrastructure just as much. Like software engineering, we design our systems and our networks, and taking shortcuts in our designs, which includes working with less than ideal designs, incorporating existing hardware and other bad design practices produce technical debt.\u00a0 One of the more significant forms of this comes from investing in the “past” rather than in the “future” and is quite often triggered through the sunk cost fallacy (a.k.a. throwing good money after bad.)<\/p>\n

It is easy to see this happening in businesses every day.\u00a0 New plans are made for the future, but before they are implemented investments are made in making an old system design continue working, work better, expand or whatever.\u00a0 This investment then either turns into a nearly immediate financial loss or, more often, becomes incentive to not invest in the future designs as quickly, as thoroughly or possible, at all.\u00a0 The investment in the past can become crippling in the worst cases.<\/p>\n

This happens in numerous ways and is generally unintentional.\u00a0 Often investments are needed to keep an existing system running properly and, under normal conditions, would simply be made.\u00a0 But in a situation where there is a future change that is needed or potentially planned this investment can be problematic.\u00a0 Better cost analysis and triage planning can remedy this, in many cases, though.<\/p>\n

In a non-technical example, imagine owning an older car that has served well but is due for retirement in three months.\u00a0 In three months you plan to invest in a new car because the old one is no longer cost effective due to continuous maintenance needs, lower efficiency and so forth.\u00a0 But before your three month plan to buy a new car comes around, the old car suffers a minor failure and now requires a significant investment to keep it running.\u00a0 Putting money into the old car would be an new investment in the technical debt.\u00a0 Rather than spending a large amount of money to make an old car run for a few months, moving up the time table to buy the new one is obviously drastically more financially sound.\u00a0 With cars, we see this easily (in most cases.)\u00a0 We save money, potentially a lot of it, by quickly buying a new car.\u00a0 If we were to invest heavily in the old one, we either lose that investment in a few months or we risk changes our solid financial planning for the purchase of a new car that was already made.\u00a0 Both cases are bad financially.<\/p>\n

IT works the same way.\u00a0 Spending a large sum of money to maintain an old email system six months before a planned migration to a hosted email system would likely be very foolish.\u00a0 The investment is either lost nearly immediately when the old system is decommissioned or it undermines our good planning processes and leads us to not migrate as planned and do a sub-par job for our businesses because we allowed technical debt to drive our decision making rather than proper planning.<\/p>\n

Often a poor triage operation or improper authority to triage players can be the factor that causes emergency technical debt investments rather than rapid future looking investments.\u00a0 This is only one area where major improvements may address issues, but it is a major one.\u00a0 This can also be mitigated, in some cases, through “what if” planning to have investment plans in place contingent on common or expected emergencies that might arise, which may be as simple as capacity expansion needs due to growth that happen before systems planning comes into play.<\/p>\n

Another great example of common technical debt is server storage capacity expansion.\u00a0 This is a scenario that I see with some frequency and demonstrates technical debt well.\u00a0 It is common for a company to purchase servers that lack large internal storage capacity.\u00a0 Either immediately or sometime down the road more capacity is needed.\u00a0 If this happens immediately we can see that the server purchased was a form of technical debt in improper design and obviously represents a flaw in the planning and purchasing process.<\/p>\n

But a more common example is needing to expand storage two or three years after a server has been purchased.\u00a0 Common expansion choices include adding an external storage array to attach to the server or modifying the server to accept more local storage.\u00a0 Both of these approaches tend to be large investments in an already old server, a server that is easily forty percent or higher through its useful lifespan.\u00a0 In many cases the same or only slightly higher investment in a completely new server can result in new hardware, faster CPUs, more RAM, the storage needed, purpose designed and built, aligned and refreshed support lifespan, smaller datacenter footprint, lower power consumption, newer technologies and features, better vendor relationships and more all while retaining the original server to reuse, retire or resell.\u00a0 One way spends money supporting the past, the other often can spend comparable money on the future.<\/p>\n

Technical debt is a crippling factor for many businesses.\u00a0 It increases the cost of IT, sometimes significantly, and can lead to high levels of risk through a lack of planning and most spending being emergency based.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

From Wikipedia: “Technical debt (also known as design debt or code debt) is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. Technical debt can be compared to monetary debt. If technical … Continue reading Understanding Technical Debt<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":1032,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[45],"tags":[240,196],"class_list":["post-997","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business-of-it","tag-it-investment","tag-technical-debt"],"_links":{"self":[{"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/posts\/997"}],"collection":[{"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/comments?post=997"}],"version-history":[{"count":3,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/posts\/997\/revisions"}],"predecessor-version":[{"id":1002,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/posts\/997\/revisions\/1002"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/media\/1032"}],"wp:attachment":[{"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/media?parent=997"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/categories?post=997"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smbitjournal.com\/wp-json\/wp\/v2\/tags?post=997"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}