Fixing It Later: Why Later == Never
Agile guru Ryan Cooper humbly suggests that fixing things later is code for "fuggedaboudit".
Ryan Cooper, evangelist for the agile programming lifestyle, offers up a blog post on why (invoking LeBlanc's law) "later equals never". (Sound advice for those who think doing things right is something that can be put off.)
- Why You Won't Fix It Later (from Ryan Cooper's blog On Agile)
This is certainly true enough. Just remember that statements like "I'll add that feature later if we determine we need it." and "I'll consider this more complicated implementation later as a performance enhancement if performance in this particular module turns out to be a real problem." may sound like variants of "I'll fix it later." but are actually statements that are very much in line with the KISS principle. Statements such as these acknowledge that any implementation has room for improvement and that said improvement may or may not prove necessary in the future. They are not statements of things that will definitely need fixing and as such should not be considered to be problems of any kind.
Comment by Misanthropic Scott — June 28, 2007 @ 1:08 pm
The problem is that the most frequent example of this syndrome is "I'll write this code in a way that allows for future extensibility and possible performance enhancement and even maintainability... later." This is why prefactoring is always better than refactoring (which rarely gets the chance to happen). The most important thing to glean from the article is the truthfulness factor—pretending that you have built something that really faster than it could have/would have taken you do it "right" only leads to skewed expectations about both delivery velocity and reliability.
Comment by Rich Rosen — June 28, 2007 @ 1:45 pm