[lt]

No, the customers only care about working software, not maintainable, perfect software.

Technical Debt is about taking shortcuts to have something working now, in exchange for more work maintaining and evolving it in the future. If the software doesn't work, it's not debt, it's a bug.

If you are not changing the software, it doesn't matter that a list is hardcoded instead of parameterizable, that the modules are tightly coupled and can't be reused, or that the build must be done following a particular set of incantations in a specific machine. If you are, these are all examples of debt that will come back charging interest.

Properly planned and managed, technical debt is a tool much like actual debt (a loan) that can accelerate your growth and your time to market. Thing is, most teams don't know that they are taking on a debt and don't realize how much interest they are paying each day.

[throwaway_djoif]

I think the path toward optimizing software for (a) maintainability (b) completeness and (c) bug-free are not necessarily mutually exclusive. I think in general software is fighting all of these battles simultaneously. And so by definition software that is incomplete (ie. without all the features) has the possibility (probability?) of being buggy. Otherwise if it's complete why add features?

Given what you knew at the time you created a definition, and per that definition you could have written 100% maintainable 100% bug-free 100% complete code. It's in uncovering your lack of/ incomplete understanding of your problem that you may need to go back in to that code. Even though at the time it was considered 100% bug-free, complete, and maintainable.

[bluGill]

100% maintainable software is NEVER a goal. A hard coded list that will never change is better than a configuration file that needs to be installed someplace and loaded as runtime. If you are right that the list will never change you have made the software more maintainable as you never have to deal all the code to load the configuration from whatever path the user has installed it to. If you are wrong though you will have a lot of work tracking all the releases and what is hard coded in each until you retrofit a loader.

This is the type of choice you need to make upfront often when designing software. If you get it right your system is more maintainable. If you get it wrong your system is less maintainable. Sometimes you don't know in advance which is right.