Recently when performing a code review I came across something like this:
WriteLabour(useNewVersion); WritePart(); WriteNonLabour(useNewVersion);
WriteLabour(); WritePart(useNewVersion); WriteNonLabour();
Now let me give you some background. This is very old code, not very object-oriented. There are always two versions of the file, the current version and the previous version. The useNewVersion flag determines if the current or previous version is to be written. The file is for a customer to consume and when they come up with a new version, they send us the new spec, we change the code to output the file as per new spec and this becomes the new version. What used to be the new version now becomes the previous version, ability to write version even previous to that is thrown away forever (that code is deleted).
The programmer was updating the code for the new spec just received. He found after deleting code for the version to be forgotten that WriteLabour() and WriteNonLabour() no longer had any version specific code, while WriteParts() now had to have version specific code. So he changed the method signatures as I have indicated above.
My suggestion in the code review was that it would be nice to keep method signatures consistent and always supply the useNewVersion flag, even if the code within the method did not use the flag. To me this made intuitive sense, because it is very likely that future versions of the file will require the flag to be passed in again and the interface for the caller would remain consistent. His argument against my suggestion was that passing the useNewVersion flag to methods that did not need it was design bloat. Who knows what other parameters the methods might need, should we pass them all in anticipation?
My gut feeling was that his argument was flawed in this particular case, but I could not counter it effectively. My question then is if there are design decisions we know are coming or by past experience, is it wrong to incorporate them into the current design even though they may be presently unused? Specifically in terms of public interfaces, method signatures etc, not private code.
But keeping code lean and not over designing is important too. Don't want to be the architecture astronaut.
Polite note: Please don't derail the topic by suggesting re-factorings for the code. This is not supposed to be a critique of the design of our legacy code. That code isn't up to standards, and I know that.