NOTE: This post is really a re-post of a reply to a discussion on Technical Debt in a LinkedIn Group. The discussion referenced a post by Naomi Bloom on called: “The Scourge of HRM Software — Technical Debt”
There is a difference between building a perfect product and building a GREAT business that serves customers well. The context and maturity of the product, company, and market play a big role in how a vendor needs to treat its technical debt. I say this half-jokingly, but if your vendor has “zero” technical debt, it must be because they’re STANDING STILL!
I define technical debt broadly to mean “anything in the product that the team knows will gate future development, any ‘hacks’ put in as stop-gap measures but that won’t scale, and any issues important to customers that have been ignored ‘too long.’”
Here are three things that I think drive a software developer’s technical debt:
1 – Maturity of the code base- Done correctly, over time, a next generation platforms is a fantastic luxury – both for the developer and the customer. But early on, the “new new thing” is a minefield of technical debt. Until enterprise software hits real customers (I use the word “hits” deliberately ;-), it hasn’t had the kinks wrung out of it. If you want the advantages of being the early adopter, just make sure you know you’re the early adopter, and that you’re willing to work through the gremlins with the vendor.
2- Velocity of new functionality delivery – this is probably just a corollary to the driver above, but it can be something to look for. The faster a company is pushing out new stuff, the more opportunity that they are not going back to pay off the technical debt it generates. _Every_ new feature can generate comments, tweaks, and reported defects. Some are not important to customers, but many are. Frequently, the pressure of a competitive market to deliver new functionality reprioritizes paying off technical debt down the list. This might be just fine. My experience is that most customers don’t roll out new features to large populations right away anyway. They just want to “know it’s there.”
3 – M&A – “Mike’s rule” (I just made it up) – “If the vendor’s solution comes from the combination of two companies, and it’s been less than a year – there’s technical debt. After a year…your mileage may vary.” Multiple technology stacks mean either re-writing functionality or adding plumbing through the existing foundation (rewriting is rare). Different technology stacks from different companies _never_ have the same underlying object model (and Naomi is right about the value of the right object model). The good news is that it is software, “everything” can be made to work, but it takes time (lots of time) and investment.
With financial debt, there is the concept of “good” debt and “bad” debt. It sounds nice to say we have “zero” debt, but of course companies regularly use debt to leverage returns for investors. This analogy will be admittedly imperfect, but in software development, choosing to “park” a portion of technical debt frees up development resources to work on other priorities of the business. It goes without saying that “too much” financial or technical debt will crash a company, but the existence of technical debt is a reality for _all_ software vendors. Yes, ask about it, but the only software that is “100% QA-ed and perfect” runs the Space Shuttle. I would probably give extra credit to the vendor’s that show some amount of transparency on their shortcomings (good luck with that one ;-).
My real point is that the stage of the company and context of the market it plays in drives business priorities, and those priorities are what drive how the vendor balances that “technical debt” line.