Is Premature optimization opposite of Technical debt

I was wondering if what was the opposite concept of Technical debt. 

Delivering work that is “Done”.

A transparent Product Backlog may help the Development Team to create a solution with an architecture not only focused on the current sprint.  

There is no optimization included in this concept. Optimization is doing something to improve value delivery.

Eliminating waste is one form of optimization. This premature "optimization" introduces waste now (time is spent while not adding value). And if that isn't bad enough, it introduces future waste as well. Time will continuously need to be spent in future spints to maintain it, still not delivering any value.

To me it seems even worse than technical debt. Both result in future waste, but with technical debt you at least don't waste a whole lot of time now.

IMO, you have to accept that you always introduce some technical debt due to the nature of the complex product development environment. So rather of overthinking solutions upfront, just keep it simple at the current point of time and improve as you go as it is needed. You may take a look at XP rules and practices: http://www.extremeprogramming.org/rules.html i.e.:

• Simplicity
• Create spike solutions to reduce risk.
• Refactor mercilessly whenever and wherever possible.

I'm not sure that there is an opposite to technical debt, at least that can be captured in a phrase.

You suggest premature optimization as an opposite, but I would say that premature optimization is technical debt. At least in a software context, optimization usually comes at the expense of readability and maintainability of the underlying code. If you didn't need the optimization to support the use of the system under design, all you accomplished is making the code more difficult to maintain. This difficulty in maintenance is likely to cause new features to take longer to design, develop, test, and deploy, which is a key indicator of technical debt.

Ian Mitchell suggests that "Done work" is the opposite of technical debt. I'm not sure that I would agree with that assessment, either. Martin Fowler wrote about technical debt quadrants - skipping or allocating insufficient time to do the work properly (such as reducing time to design, or more often, to test) would be technical debt and also in the category of work that isn't Done. However, other types of technical debt can be incurred in work that is Done. A prime example of that is learning by doing - you may learn better ways to do the work as a result of doing it, but the work may meet your Definition of Done.

I'd argue that technical debt just exists. It exists, in some level, on all projects. Hopefully the technical debt that you incur is prudent and not reckless. That is, appropriate discovery and refinement is done to understand what work needs to be done and what it means to be done as well as to gain an understanding of the required technical solution. When you incur technical debt, you do so knowing the risks, accept those risks, and hopefully have a plan to mitigate those risks in the near future.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

I disagree with that statement.  It is one form of technical debt but it is not the only source. For example technical debt can occur when you choose to deliver new features instead of upgrading versions of core architecture. It can occur when you add code to a solution because "it might be needed in the next release".

Premature optimization is spending a lot of time on something that you may not actually need. 

I have a differing view.  Spending a lot of time on something that you may not actually need is what I consider over analysis. It is considered "waste" in an agile world but it isn't the opposite of technical debt.  In fact it is usually a cause of technical debt because often the over analysis introduces unneeded code. 

I think that @Thomas Owens' closing statement sums it up very well.