Issue: New software functionality needs to be added to your enterprise content management system
Option one: quick, “down and dirty” approach that will most certainly cause issues for all further down the line
Option two: a more thorough design approach that will take longer than option one (above)
Option one sets us up with a technical debt according to Ward Cunningham. Technical debt is quite similar to a financial debt in that they both have interest payments in common. What I mean is that there will be additional effort and time spent in the future because of the initial design choice.
Again, we are presented with two options.
Option one: continue to pay the interest
Option two: pay down principal by re-engineering the initial design into the improved design
Real-world example: customer timeline is short. New functionality built. Parties agree to deploy phase one deliverable into development environment. Initial timeline met, code delivered to client. Client deploys code directly to production environment. Issues occur that increase stress for both parties.
Technical debt can be good or bad.
What makes this so interesting for those of us in the consulting field is that we must deal with technical debt while also reconciling it with the financial restrictions and timeline necessities of clients. Meaning, we all need to be aware of this debt, and inform customers of this debt, but we will often need to live with it as a reality despite “knowing what’s best”. This is written with complete humility. Why? Remember that we have been hired for our expertise.
