Health knowledge made personal
Join this community!
› Share page:
Go
Search posts:

Understanding the balance between Systems Delivery and Technical Debt

Posted Nov 17 2009 10:02pm

Technical Debt is a new metaphor courtesy of Ward Cunningham, which has arisen the past year. Technical Debt refers to the repayment of time when taking the fast and easy way for implementation. Technical Debt originally started out as an programming concept, but I'd like to expand it to the systems side of the house.

Let's imagine you do not have good business governance, and IT always finds out way to late in the process systems are being contracted. This arises in an organization of cowboys, just really concerned about getting the job done. So you get this job done, as quickly as possible, then the next implementation, then the next. The organization knows there is a better way, but always finds them selves in a reactive mode. Over time the lack of architecture is really a mess. The organization's infrastructure is rigid and brittle. Making a change here has a ripple throughout 4 other system, which just might break one of the system. Quick adaption has gone away making the structure rigid. However, most changes have side affects and impacts, bringing a brittle nature to our infrastructure. This is simply a bad situation, which will take focused concerted effort to resolve.

Now is the questions, is this mess really Technical Debt? Some say no, it is just a mess. I say yes, and here is why.

There is a balance between well-architected and implemented systems with the timeline needed and available resources to get the work accomplished. Technical debt arises when short cuts are taken to achieve the customer's satisfaction. These short cuts cause workarounds and additional work while maintaining the system. In the above scenario, we have technical debt because we knew a better way, but chose a different path, hence our technical debt.

Lessons Shared

In summary the lesson here is simple, as management there is time always time to rework a solution, however the cost of poor quality is rework and additional maintenance to keep this system running. This technical debt needs to be evaluated compared with the ability to deliver constantly in a reactive setting.

Hopefully you have enjoyed this post, please also check out:


Post a comment
Write a comment: