So, you’ve got your scope creep, and you’ve got your feature creep. Lately, though, I’ve been thinking a lot about a little gremlin I’ve been calling “future creep”.

Future creep is not about adding features to your products. At least, it is not directly about that. Rather, it is about adding infrastructure to your products in preparation for features that may or may not be added later. In the future.

This is really subtle, because it can happen even (or perhaps especially) when the feature list for a product has been frozen. So, sure, you can’t add any more new features for this release, but there has been talk about some new feature X being added eventually, and if you just tweak the code a bit here and here, and maybe there, the way can be paved for X that much more easily!

That feature X can be anything: a programmer interface (API), a drag-and-drop UI, element categorization, data export/import, batch processing, anything at all, anything that you don’t intend to implement immediately, but which has been bandied about as a possible addition someday.

Paving the way doesn’t sound bad at all, though, does it? In fact, it sounds proactive and laudable. And if that feature X goes through in a timely fashion, exactly as you envisioned, I’m sure you’ll be praised for your foresight.

BUT.

Even the simplest of potential features can be implemented in a number of ways. Or not implemented at all. At best, your “foresight” can result in wasted time, where you spun your wheels for a few hours (or days!) playing “what if” and “let’s pretend”, trying with too little information to think of how best to architect your code to accommodate that future feature.