Infrastructure Creep

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.