The process by which sensible thinking ahead turns into techie playtime as the designers/builders add yet another feature to the infrastructure/framework because it's "sure to save time later," rather than get down and build the application.  -- TomAyerst

A variant of FeatureCreep, where the features are all internal?

----

Any extreme is bad. More of what I see is no infrastructure and every
subsystem doing things their own ways. This leads to a system with
no LeveragePoint''''''s and makes the system very hard to evolve. It's not often that programmers will brave the social risk of creating and
advertising something that can be reused.

''Given my POV, it is unsurprising that a very significant factor in the most spectacular project train wrecks I have been involved with have been out-of-control infrastructure teams. -- TomAyerst''

I guess in 18 years I just haven't seen this very often. I usually see
the reverse. The drive to make schedules causes all thinking to be
truncated in favor of "many little rivers flowing to the sea." Maybe
in larger companies this is more common. But in Silicon Valley I have
to say it is far less common because the time pressures have been so
great. Where architecture has been emphasised it has worked very well.
I don't really see something like "to make this string class we'll have
write our own OS." And some of the XP discussions of infrastructure 
strike me as very naive. One XP guru's idea of a database infrastructure was to use the native API from a database vendor. When the inevitable happened and the API failed them, the fault was infrastructure. The fault was really theirs for horrible system design. -- Anonymous

''Where is this story documented? I'm an "XP guru" and hang out with most of the others, and I never heard of it.''