To focus on the problem is certainly good advice, if they mean the domain problem by it, and not the OOP modeling problem.
It sometimes seems to me that code is the only medium in which the Agile/OOP/TDD people are allowed to express themselves; writing down a formula or a problem statement in prose probably is "too upfronty" or "too waterfally".
Stepping away from the medium of code, which always expresses an implementation (i.e. a solution), but not a problem, brings you back to the domain.
On the other hand, writing the series of blog posts honors the problem itself in a certain way: since it didn't work to just write down the code and to knead it into correctness, a medium more detached from the solution was chosen.
When a programmer steps away from the medium of code, he's probably well advised to also approach a domain expert, for he's too far away from solving the problem.
To focus on the problem is certainly good advice, if they mean the domain problem by it, and not the OOP modeling problem. It sometimes seems to me that code is the only medium in which the Agile/OOP/TDD people are allowed to express themselves; writing down a formula or a problem statement in prose probably is "too upfronty" or "too waterfally". Stepping away from the medium of code, which always expresses an implementation (i.e. a solution), but not a problem, brings you back to the domain. On the other hand, writing the series of blog posts honors the problem itself in a certain way: since it didn't work to just write down the code and to knead it into correctness, a medium more detached from the solution was chosen. When a programmer steps away from the medium of code, he's probably well advised to also approach a domain expert, for he's too far away from solving the problem.