I've been educating and coaching a fair share of projects in TDD and agile practices now, and in one there was a developer that decided against the harsh discipline of TDD/BDD and agile. The reason was his love for coding away at a solution, going as far with it as he could envision (which he was very good at btw).

The principle of YAGNI has to do with focusing on current needs and satisfying only them, as prioritized by the customer and/or as is evident from the backlog (xp and scrum). It's related to the well known issue of design partitioning.

On this project, we used the term or token "golden future" to claim that we were reasoning about issues that were far from where the project was. Another term that made an entrance was "deep" coding. This is used in many places to mean locking yourself up and focusing on a problem, usually also a problem that requires the dev to go deep into the underlying technology to find a solution.

Here we meant something similar, but referred to the solution space (rather than the technology/system space): To code "deep" was to take a task / user story and develop it as far as the dev could at that point in time. A spike, if you will.

My point here is that the term has a positive ring to it, in the ears of the engineer/developer. To go deep and solve something hard requires skill and means that you are doing hard and complex work.

We would probably have been better off to choose the term to code "far" or code "away". Coding far means to wander off in one direction, hoping that it is the right one. It means to never check the map or the compass until you are feel "done" and have exhausted your vision knowledge. By then you are far out in the forest, all alone.

Are you close to your destination? Or did you just spend alot of time wandering?