[mercer]

> Work through several specific examples before trying to solve the general case. Looking at specific real-world details often gives an intuitive sense for what the relevant distinctions are.

This describes well why I like the more functional approach to programming (whether within an OO framework or otherwise). I often find myself solving a problem a number of times before I abstract it. And usually creating said abstraction before the problem appears leads to over-engineering.

When writing 'functional' code, I come up with solutions that are isolated enough that I can later replace them with various more abstract solutions, whereas the more OO or procedural approach can leave me with a mess that is too much work to disentangle.

[bonestamp2]

I'm the same. One of my work projects is a fairly large code base and we add new features to it regularly. When I'm adding a new feature I generally prototype it all in one file (or at least as few as possible).

Once I have something working, I try to simplify it, then I look at the relationships within the code and as it interfaces with other code. The abstraction usually becomes quite obvious at that point. This approach of starting "dirty" usually results in very clean code at the end of refactoring. If I try to start clean, it is usually far dirtier and I end up changing much of the architecture anyway. So, it seems more efficient to start without any architecture and then tailor fit at the end.

I guess it's like writing text, it's best start with a rough draft to get the ideas down, then you can organize it once you've got a working version.