Some sketchy thoughts about design

There is an idea, that seems to be a truism, that programming doesn't require any upfront design. That TDD is a design tool and as you write your tests, get them to green, refactor, you are designing. I guess I can see that.

There is an idea that all programming is design and the compiler or interpreter is what "builds" the program.

I think that there is always up front design, when I write a line of code there is a design to it, if design is arranging things so as to get the desired result.

What is design? The purpose, planning, or intention that exists or is thought to exist behind an action, fact, or material object.

In TDD by Example, I think Kent Beck does a lot of "upfront" design, it just happens to be all in his head.

Sometimes I have no idea what line to write and then I think about the problem, maybe break down into a series of smaller problems and then I can start. Is the act of breaking down an act of design?

In GOOS there are a lot of upfront design decisions that are made, that are not really explored. What trade-offs were considered in choosing to the application in the Java framework "Spring"? What were the alternatives? If you do not have alternatives did you make choice?

Much of the programming I do is on autopilot. I just follow conventions. I wonder if I ever actually make a choice?

Is it really decision if I didn't consider at least one other way of writing it?

Best practices are starting to feel like the best to not have to think about anything. Because thinking about something and trying out a different ways of doing things, means that most of the ways you try won't work. You might not come up with a better way than the "Best Practice" so you cost the company money. It's probably why the most interesting stuff happens away from work. It's a shame.

It's probably ok to re-invent the wheel every once in a while. Just to see if you can end up somewhere different. Maybe you can come up with a better wheel, maybe not.

What the writer of GOOS make early on are architectural decisions. How is architecture different from design? Is it just the design decisions that are going to be really hard to change later on? The "important stuff" as Martin Fowler puts it.

There is a book called 99 Ways to Tell a Story which is the comic version of an older book called Exercises in Style. Both books tell the same story 99 different ways. Can I write a program that does the same thing 99 different ways? Could I do it with one programming language? Does the choice of programming language limit the choices you can make?

More and more I'm thinking that the best way to program is to actually create a language to solve problems in that domain. I think it will require a deep understanding of the domain to be able to write a tool that solves the kinds of problems one encounters in that domain. If you can fashion the lever, you can move the world. You probably need to account for the fulcrum, it needs to be in the right place.

We are the geometers of ancient Egypt whose main value was to help plan around the flooding of the Nile. Euclid hasn't come along yet.

I have this inkling in the back of my mind, almost everyday, that if we had the right tool, most of the actual technical problems would be trivial. But then again, maybe we should just make bigger problems for ourselves.

Finding the right metaphor is an underrated part of programming. If we can find the right metaphor, the rest of the solution unfolds from it like a lily. The right metaphor makes everything clearer and could be the basis of the domain specific language. How do you get to the right metaphor?

My favorite definition of metaphor comes from Sister Miriam Joseph, in the book The Trivium: The liberal arts of logic, grammar and rhetoric.

Metaphor is the use of a world or phrase to evoke simultaneously two images, one literal and the other figurative.(It is deliberate ambiguity of images).... Aristotle regarded the metaphor as a compresses proportion, a statement of equality between two ratios. The full proportion may be represented thus: a:b:c:d. The compressed proportion is a is c

She gives some illustrative examples:

O Wild West Wind, though great of Autumn's bing.(a is c)

--Percy Bysshe Shelly, "Ode to the West Wind"

The West Wind (a) is to Autumn (b) as breath (c) is to a human being (d). (a:b:c:d)

Love.. is the star to every wandering bark. (a is c)

--William Shakespeare, "Sonnet 116"

Love (a) guides a wandering soul (b) as a star (c) guides a wandering bark (d). (a:b:c:d)

The moon is a boat. (a is c)

The moon (a) moves through the sky (b) as a boat (c) sails over the sea (d). (a:b:c:d)