Premature Abstraction

Pending a description, see PrematureGeneralization, TooMuchAbstraction, YouArentGonnaNeedIt.

Q: Just what is premature about abstraction? Is there a time in a process when abstraction is appropriate? Isn't abstraction a precursor to development? Just what is a PrematureAbstraction? Has it a generally accepted description or is it just a spin-off of PrematureOptimization?

Isn't PrematureAbstraction when you form an abstraction before you understand the problem well enough? See ThreeStrikesAndYouRefactor.

Why delay Abstraction?

Very often, YouArentGonnaNeedIt. For example, you might have zero or one instances of this abstraction.
You probably have something better to do right now. (FutureDiscounting.)
With only a few exceptions (such as sharing an API or DSL and thus introducing backwards/forwards compatibility issues) it is no more expensive to introduce the abstraction later than it is to introduce it today.
It is easy to introduce overly restrictive abstractions (where you'll need to later work around them) or overly general abstractions (where you'll have difficulty reasoning about or optimizing the resulting program). By delaying abstraction, you can gain a better idea of what you need.
Developers historically have a difficult time grasping simple, powerful abstractions (such as monads, applicatives, monad transformers, arrows, rings, semigroups, monoids, fields) before they, personally, have used multiple examples and seen how the operations and principles broadly apply. There is often an EurekaMoment. In a long-lived project, you cannot assume that maintenance developers will grok abstractions that are much higher level than normally offered by the language and existing standards.
Not all languages are abstraction friendly. Many will make you pay through the nose (in terms of time or space) for each abstraction as a LayerOfIndirection. Many languages fail to adequately support developers in identifying and specializing instances based on context or type.
Parametric abstraction often introduces syntactic overheads that a more concrete implementation might lack. Developers rarely wish to deal with these overheads unless they're getting something out of them, which means having at least two instances.