Mircea Zetea - Managing technical debt
Technical debt lives among us regardless if we are in the services
business or building products.
We discuss about it, we try to fix it or live with it, but can we
actually prevent it?
My reason for discussing this openly is because once it is there you
do not only deal with the technical debt itself but also with the
interest you must pay.
What qualifies as debt? What qualifies as interest? How do we manage
it? Is it really unavoidable?
-----
Technical debt lives among us regardless if we are in the services
business or building products.
We discuss about it, we try to fix it or live with it, but can we
actually prevent it?
My reason for discussing this openly is because once it is there you
do not only deal with the technical debt itself but also with the
interest you must pay.
My reason for discussing this openly is because once it is there you
do not only deal with the technical debt itself but also with the
interest you must pay. Comparing the two, probably the highest cost
that we see is with the interest.
As our code base grows and our deadlines get tougher we tend to
forget about the cost our project will have to pay for every
functionality that we implement in a hurry, for which we “forget”
about tests or for which we write in a comment “this needs to be
refactored” or “this is a temporary solution. refactor later”.
What qualifies as debt? What qualifies as interest? How do we manage
it? At what levels in our projects can we see the debt and the
interest? Is it really unavoidable? |