The problem with that line of thought is that it assumes that you are able to plan correctly. I would argue that, as long as you are working on an interesting problem, this is inherently impossible. What do I mean by interesting? I mean it in a very subjective sense: interesting is what is new and challenging for you and your team.
If what you are doing is new and challenging for your team, this means that you probably don't understand the problem perfectly yet, which means that you are only able to guess at what the ideal interfaces are. It might turn out that your guesses are correct, and then you're very lucky. It might also turn out that your guesses are wrong, and then you're causing yourself a world of pain by working towards the specified interfaces. If you defined an interface J between two modules A and B that is not good for its purpose, then both A and B will have to work around the weaknesses of interface J, introducing shim code that is a likely source of bugs. Since there are so many ways of defining interfaces, I would argue that the likeliness of getting it wrong is relatively high in a situation where you don't understand the problem too well. It would be better to simply evolve A and B together with J at the same time, so that lessons learned while implementing A and B can influence each other and the interface.
If what you are doing is boring (in the sense of not interesting as defined above), i.e. you already understand everything about the problem, then you may indeed be able to specify interfaces perfectly in advance. Then again, if that is the case, why are you bothering with reinventing the wheel in the first place? If you understand everything about the problem, it means you have solved it before, or seen an existing solution, so why don't you just reuse and adapt that existing solution?
Ultimately, this is simply my take on the whole waterfall vs. agile debate.
While I agree, there is plenty of uninteresting problems that are easily monetized.
Not to misrepresent my actual outlook. I support agile, I just think a lot of people use agile as an excuse to not look at the bigger picture and develop an efficient system before developing solid components that make problems like this.
