Please login or join to subscribe to this thread
There is a big missunderstanding about technical debt outside there. I can talk about that because I worked with the people that "invent" the concept. Unfortunatelly sometimes is taking as a mean to justify the dream about agile is about deliver fast. First of all, agile was created with quality as one of its pillars so no technical debt or similar is accepted. But in quality theory you have two key concepts: quality and grade. The key is getting a balance between quality and grade and like eveything in quality it is an strategical decision. You have to decide to create products with low quality and high grade or the contrary. Products with low quality and high grade you will find a lot mainly in software industry as an example. So, technical debt is closely related to grade concept. How you manage that is up to you in the framework of strategical decisions thru quality. Re-factoring or all other techniques can be applied but if and only if everything is considering until maintenace framework (preventive-corrective-adaptative).
It comes down to the magnitude of the technical debt. Yes, for small volumes of it relative to the overall "size" of the solution, refactoring works well.
But imagine a legacy application developed one or two decades back which has been band-aid'ed frequently. In such cases, refactoring out all technical debt might actually cost more than a replacement, especially when the poorly maintained code is combined with a lack of automated regression testing.
Actually, that is another good example of technical debt - large, complex technical solutions with no automated regression test repositories. The cost of creating these from scratch to provide sufficient coverage is way more than any company would be willing to spend money on.
Thank you again, Sergio and Kiron, for your provocative and thoughtful replies.
In software development technical debt refers to code that is hard to maintain and further develop. Technical debt is something that only developers can understand and "feel".
Non-developers as well developers who don't directly work with a specific peace of code can't tell it that code suffers of technical debt.
Also if some developers have worked with a product for a very long time they would get used to it and they would not "feel" the technical debt anymore, at least not at the same intensity. For new developers however it would be very hard to start working with code that suffers of technical debt.
For managers it is hard to manage technical debt as they can't see it unless they are hands-on and they try to work with the code themselves.
If you want to do some bigger changes in a certain area then the best solution is to refactor that part of the application so you can easily develop features related to it.
Trying to refactor the whole application, for me as a developer, makes no sense. Also it makes no sense to replace the application just because it has technical debt. If the new application is written under big pressure from management to finish faster then it can result in having even more technical debt that the legacy one.
This goes back to ensuring that your Information Systems match and exceed the business requirements. Anything else it just wasteful.
Like every department in an organization, IT has an annual budget that is drawn up in advanced where scoped project costs and fixed recurrent costs are included.
Computers and information technology were originally brought into organization in order to improve efficiency, that is a better, quicker and cheaper way of completing a process.
As a result this drove efficiency, reduced implementation costs and recurring cost of implementing a process.
As a result, IT was seen as doing such a good job that it got its own department and a annual budget.
So now IT was expected to continuously implement new process to increase efficiency and production.
However this initial rapid increase in efficiency has been seen to taper of in the recent decades and now efficiency and cost reduction is found by using shared services, ubiquitous devices, bring your own device policies and cloud enabled web technologies.
In some way IT has become a victim of its own success and now has reached a technical glass ceiling.
So now the term Technical debt has been introduced which is a piece meal approach to a problem using the available resources and timeline.
So the way to avoid getting hung up on this 'problem' it to work out the cost implication to the business by implementing a solution that maybe a overkill or just solve the immediate problem.
If the business requirements are met and the problem is not business critical them all you are doing is making a decision based on the present business requirements rather than what may happen in the future.
A risk assessment on the problem may make the approach cost prohibitive and not necessary.
I agree with Sergio
Please login or join to reply