I always appreciate someone coining a useful expression, but I gotta say, sometimes these coiners are trying a bit too hard, no? I think I'll stick with "exploration-based", "exploratory" or "explorative" programming, which are commonly used and all sound less awkward to me than than "discovery coding". But hey, if that's what people flock to I'll get with the times! I've always used a combination of both approaches and the descriptions made here are great.
I agree, "exploration" style ... learning. Exploration is what we are in control of. Discovery is the natural and expected result, but isn't in our control.
Exploration style "learning" applies to anything.
But the phrase "exploration oriented development" does make sense. Given the useful and growing list of "X oriented development" paradigms that have been identified.
Exploration is especially good for:
1. Learning how to create things for fun.
2. Building solutions in unfamiliar areas.
3. For the most challenging greenfield problems and solutions.
In all cases, jump in, try things. Iterate as fast as possible to identify the most significant problem, define it as clearly as possible, find the smallest possible version of it, and try every angle to solve that. Then reorient and repeat.
Exploration is the right word, because you are letting the terrain guide you to unexpected problem perspectives, solutions, and means. From a learning goal standpoint, it is extremely efficient, and the specifics and wisdom discovered are often original.
I have spent my career doing greenfield work, chosen by me, which must be rare. Every day I push as hard as I can on the smallest problem surface I can find. The downside is that rate of progress is unpredictable, chaotic with very high deviation. And sometimes you expend a lot of time working your way into a real dead end. Another is the amount of code discarded can dwarf the final code by orders of magnitude.
