... the nature of design, as they discovered, is so intensely cognitive, happening inside the mind at mind speed, the researchers could conceive of no useful tools to help in that process!
This is exactly my experience. The closest is diagrams with pen-and-paper, but it doesn't help that much. The more difficult part is not solving the problem, but showing that you've solved it i.e. a proof, for all possible cases. Finding a proof of a solution is as much work (if not more) than finding the solution in the first place.
It is by logic we prove, it is by intuition that we invent - Henri Poincaré
The article is talking about consciously formulated conjectures, not about instantaneous insight, discussed here: p.62 of Intuition in science and mathematics: http://books.google.com/books?id=qqGWlEwWj5UC&pg=PA62...
Particularly when modeling CS structures, mathematics feels like programming (to me). This makes particular sense when you reason about CS structures using constructive logic -- then it is programming.
However, my experience is that adding extra constraints to a problem makes it harder and more complex to solve, whereas separating out different aspects (divide&conquer) makes it easier. Jack of all trades/serving two masters etc. That is, you'll write better code if that's all you're doing; and you'll write a better proof if that's your sole purpose. "To hit a bird on the wing your whole mind must be on that bird..." etc.
Ironically, the power I personally find in a mathematical approach is that you can freely separate out constraints in any way you like, regardless of usability or performance, in order to show some quality clearly. Combining the proof with code pushes in the opposite direction - and for me, when it's at the max complexity, this pushes it over the threshold.
I still think it's cool though, perhaps mostly because it provides an automatic test of theorems.
I don't build models until I know which actors in the system they represent. And I only do that because OOP is built to deal with this kind of system-building.
I try not to fulfill the requirements but to require fulfillment; build, define the problem in the terms of a solution. That works for me.
Sometimes you need to break down the problem into smaller problems to do that.
I'm not sure which concepts your words refer to e.g. what is it in "how it all worked"? which models do you mean in "I don't build models until" (in the article, models are mental models, and it uses the term representations for their representation in code or notation.
Languages aren’t design; they’re representations for writing down the design once we get it.
Quit thinking of external representations as what design is all about, and focus on mental process.
By representations of design, he means something more concrete and less fluid than mental models. Even mathematical notation is less fluid than mental models, because they presuppose the terms of reference, which is a solidification of a model, which makes it harder to even visualize the problem in other terms.
BTW: lisp is more fluid than java, but less fluid than mental models.
Let's say you have a book. The ideas are the model and they can be adapted into various representations such as the book, a magazine excerpt, a movie, a musical, etc.
I think he means that the people who have trouble with design are those who focus on solving the problem that the representation demonstrates rather than solving the underlying problem (which is in the form of the model). So the solutions are specific and brittle rather than general and adaptable. Or something like that...
