Comments on: Future Creep – You aren’t gonna need it!

By: AndrewWoody

AndrewWoody — Sat, 18 Apr 2009 03:28:51 +0000

A great related article talks about agile document, and the You Aren't Gonna Read It approach.

http://www.agilemodeling.com/essays/tagri.htm

By: AndrewWoody

AndrewWoody — Tue, 31 Mar 2009 06:15:47 +0000

Andy,

Your stumbled on one of my other favourite topics with the line... 'not least as I need to be able to test it on my system!' So the code you added was not so much Future Creep but part of creating testable code.

I may be stretching your point somewhat, but I'm still convinced that in the long run and even taking these examples into account not adding Future Creep will result being more productive, producing better quality code.

By: AndrewWoody

AndrewWoody — Tue, 31 Mar 2009 05:15:47 +0000

By: The difference between “Future Creep” and writing good code « Brian Farnhill

Mon, 30 Mar 2009 23:57:31 +0000

[...] good post from Andrew Woodward (a MVP from the UK) about the concept of “Future Creep” (read it here). Basically he discusses this idea that when a developer puts in a piece of code that isn’t [...]

By: Software Quality Digest - 2009-03-18 | No bug left behind

Software Quality Digest - 2009-03-18 | No bug left behind — Wed, 18 Mar 2009 20:46:15 +0000

[...] Future Creep – You aren’t gonna need it! – “How many times have you added an additional parameter or bit of logic to your code because you thought it could be useful and it’s easier to add whilst your already changing the code? If you are your introducing Future Creep! and should stop doing it.” [...]

By: Andy Burns

Andy Burns — Tue, 17 Mar 2009 22:56:30 +0000

Depends what you're doing, and who you're talking to. I'm not sure I agree with never adding support for future functionality – you have to use judgement. I guess I'm with Matt on that.

Example – last year I wrote an Outlook 2003 to SharePoint 2007 plugin. The customer insisted (with absolute certainty) that emails would always be saved as one content type, and I could just hardcode the form to fill in the item's metadata. They also kept telling me to “just 'hardcode' everything” 'cos the integration would only be used on their system, and clearly it'd make development so much faster

I judged that they didn't know what the hell they were talking about. It was clear to me that they would need to save emails as different content types, and it'll be a cold day in Hell before I “just 'hardcode' everything” – not least as I need to be able to test it on my system!

Adding the dynamic generation of the form to fill in the content type data was a fair bit of effort – a lot more than building a fixed form. If this functionality had never been used it could easily have been seen as future creep. A week after I'd finished it they needed to save emails as more than the one specific content type. The customer was quite chuffed to discover that we could support that and wouldn't have to spend time in change control.

I think that if you've got a clear and tightly defined requirement then yes, just get it done. And there is a temptation for developers to try and be clever and gold plate things (well, some developers, anyway). But I wouldn't just ignore what I think is likely to happen in the future, especially in some cases where adding the extra functionality in later is much harder than doing it up-front.

And while less code is good… …we are talking about SharePoint here! ;p

By: Matt Taylor

Matt Taylor — Tue, 17 Mar 2009 15:00:49 +0000

I always admire (and envy to an extent) people who take such a definate stance. Your words will certainly make me think twice the next time I am tempted to do something like this but experience tells me that the only time you can ever be gauranteed to make the right judgement is in hindsight. I have many examples where my instinct to add somthing outside of the requirements has ended up paying dividends but equally I can remember situations where I caused myself (and possibly others) more work by doing the same.

By: AndrewWoody

AndrewWoody — Tue, 17 Mar 2009 01:59:42 +0000

IamACoder, personall I would refer to FEATURE creep when the code in question actually add's some additional feature. FUTURE creep as in this post is where the developer add's some additional code to support a possible future feature. A small but significant difference

By: IamAcoder

IamAcoder — Mon, 16 Mar 2009 21:28:01 +0000

Don't wish to be a total pedant, but it's actually FEATURE creep.

By: SharePoint Daily for March 16, 2009 - SharePoint Daily - Bamboo Nation

SharePoint Daily for March 16, 2009 - SharePoint Daily - Bamboo Nation — Mon, 16 Mar 2009 13:36:23 +0000

[...] Future Creep – You Aren’t Gonna Need It! (Andrew Woodward)How many times have you added an additional parameter or bit of logic to your code because you thought it could be useful and it’s easier to add whilst your already changing the code? If you are your introducing Future Creep! and should stop doing it. [...]