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.
What does Future Creep mean?
If your from from an XP (Extreme Programming) background you would know this better as YAGNI, You Aren’t Gonna Need It! I actually prefer the term Future Creep I first saw on the post, beware of future creep by Jamis of 37 signal. Everyone understands the terms Scope Creep and Feature Creep and its easy to spot these, although often ignored. Future creep is the adding of additional code by the developer because they can see a possible future requirements.
DONT DO IT!
You may think, hey it’s only gonna take me a couple of minutes to add this additional parameter which I can see being really useful in the future. You add the code and then move on, from that point forward that additional code needs to be maintained, every time a developer interacts with your code they need to read it and understand it – often taking more time as that bit of the code is never actually used, which leads to uncertainty about the code.
It happened to me
The reason I wrote this blog post was an example of future creep on a recent project that had a measurable impact on time and effort. The future creep was was simple, the developer was writing a light weight logging library and decided as part of the Logging.Log() method that if the code had a HTTPContext they would also initialise the current web using SPContext.Current. None of the code within the internal methods made use of this it was just setup and passed into the method. This in itself does not sound to bad and for most scenarios the code did run with a valid SPContext h0wever this future creep caused a number of issues which forced developers trying work around it
- The logging library could not be used in code that had elevated privileges as SPContext.Current throws an error if accessed under a different security context
- The logging library could not be used where a HTTPContext existed but no SPContext, as was the case for some of the Exchange integration code
Having battled with solutions to the second scenario and getting comments about not wanting to make changes to the Logging Library because the dev was not comfortable with the way it had been implemented I challenged the original author of the code as to the requirement for SPContext.
The answer: Future Creep
A few minutes later the extra code was refactored out, and the library could be used.
Lessons Learnt and how to prevent it?
Don’t do it, resist the temptation, remember:
The best way to implement code quickly is to implement less of it.
The best way to have fewer bugs is to implement less code.
And adopting techniques like Test Driven Development force you down a path that doesn’t allow it.
