My secondary school physics teacher (the incomparable Mr Peter Rouse - if by chance you ever read this, hello and thank you) used to say that the key to solving problems in Newtonian mechanics was a carefully cultured, selective form of myopia. The idea was that this allowed you to construct the simplest set of equations that adequately described the scenario in question, ignoring complexities that made no meaningful contricbution to the final solution (e.g. obvious exclusions are relativistic and quantum effects, which have no place in "classical" physics, but more useful are the frictionless surfaces and massless pendulum strings that abound in this strange, simplified universe).

I believe much of this also holds true for good software design, which should be concentrating on its implications in the customer direction, rather than giving too much consideration to how a given design might be implemented (I'd argue that security issues propagate in both directions, though, so should not be overlooked). However, as someone who started out doing 100% development but has since progressed to having more and more of a design role, this is something I find extremely difficult. As I have done over two years of on-site customer consultancy work, the first part does not trouble me greatly. My problem lies in the fact that even while I'm just sketching a quick UML class diagram, some part of my brain has already normalised the database schema and is now setting to work on secondary indexes (I'm sure that's somewhat of an exaggeration, but on small projects it sometimes feels that way).

Does anyone else relate to this? If so, have you found anything that combats these "implementor" tendencies, or is it simply a question of self-discipline and even more practice?