

A Different Look at Software Design - visitor4rmindia
http://www.developerdotstar.com/printable/mag/articles/glass_cognitive_view.html

======
10ren
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é_

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...](http://books.google.com/books?id=qqGWlEwWj5UC&pg=PA62&lpg=PA62&dq=anticipatory+intuitions&source=bl&hl=en&sa=X&oi=book_result&ct=result&resnum=5#PPA62,M1)

~~~
mgreenbe
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.

~~~
10ren
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.

------
anonymousDan
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..

~~~
10ren
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.

------
mlLK
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.

