He's saying design is trial-and-error, but it helps to have an approximately right model to start from. It seems to me that mathematics could lead us directly to the right model without mistakes... or is the truth that the same trial-and-error still occurs, but just in more abstract and general terms? Does that seem right to the mathematicians here?
... 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é
Building a mathematical model is also a process of trial and error. Which definitions are necessary? What are the invariants of the structures you build, and how must those structures interact?
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.
I think programs that are proofs (as in COQ) is a cool idea. It seems economical, in that you get two things (a program and a proof) for the price of one.
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 think you may be doing it backwards then. Trial-and-Error, or mental modelling were working out fine for me when I was just starting to learn how it all worked. But now it's down to critical and logical thinking processes.
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 really not following that - can you clarify please?
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.
Refers to building systems in general. How do you build a solution to a problem? This is a skill, and it is learned and taught.
> …don't build models…
Refers to mental modelling, correct. I don't do that until I have broken the problem down into mentally tangible pieces, and then – only to accommodate for the particular tool that I'll be using – i.e a programming language/famework/hardware of this kind or another.
Does anyone have any idea what the difference between a 'model' and a 'representation' is with regards to this article? They seem to emphasize the importance of using the former instead of the latter, but I have no clear model(!) of the distinction between the two..
His full term is "representations of design", and he uses it previously in the following ways:
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.
Representations are different ways of looking at the model.
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...
His 3 step iteration for the 'Essence of Design' reminded me of WikiWikiWeb's 3 step iteration for HowToLearn [http://c2.com/cgi/wiki?HowToLearn] They're strikingly similar except the language for learning is far more abstract and generalized.
... 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...