Code, Picasso, and Simplicity

What I find interesting about The Bull is how Picasso's initial breakthrough is to reduce the prominent head to a small insignificant shape. Only with that done can he go on to reduce the rest of the body to such a degree. To me that demonstrates how attacking a problem from an unusual angle can yield an unexpected development, when trying to reduce the more obvious components first would probably result in something more like a bull and less like a work of art.

cf. http://synthcode.com/blog/2009/06/Small_is_Beautiful

Fred Brooks says to plan to throw one away. It won't directly help you keep your final product simple, but if you don't worry about making your first pass beautiful, you can get through it faster and learn all the details about your solution sooner. From there you can simplify. (I'm talking at the level of writing a function or two at a time, then simplifying)

I like to throw together my first try however feels easiest. Special cases, multiple loops, wrong data abstractions, whatever. Once it works, I look at the big picture: where are my data abstractions hurting me? Where can loops be combined? what macro-scale blocks of code could be re-shuffled to be clearer. Then I recursively look at subsections until I've gone as far as removing the superfluous variables and ensured everything is named sensibly. Then I push the commit (not earlier, or it's too likely to be interpreted as 'done')

As far as anti-patterns that lead to unnecessary complexity:

* Is anything un-idiomatic (Python especially)?

* Is the same information stored/handled in more than one place?

* Is any variable being asked to do double-duty?

* Are errors being detected/signaled/handled too early? Too late?

* Can the data be re-organized to provide a more natural problem?

* Are there un-necessary branches? (Where applicable, develop an algorithm that works for all inputs, instead of seperate algorithms for different classes of input)

* Has anything been added because it's "basically free"?

I think the impulse to simplicity and the ability to recognize complexity comes from experience.

I'm sure Picasso wasn't "just" Picasso from day one. He probably spent most of his early days absorbing as much as he could as we all do when we are young and without experience. When we cannot absorb any more some of us, like Picasso, begin to find ways to simplify our understanding of the structures that beget such complexity so that we can find the intellectual room required to reflect and absorb more.

As with code and mathematics -- we may come to understand our problems and meet them with complex solutions. Yet only experience will reveal the underlying structures. After you've written the same kinds of programs a hundred different ways will you begin to see commonalities and short-cuts.

And personally I find that experience outside of programming also helps to find that elusive simple elegance we all desire our code to have. I study mathematics, fine art, literature, music all because I've found that ideas in one often reveal through lateral thinking -- solutions to problems in the other. That's why I love programming so much.

I find that both when writing code and when writing papers I usually just try to get my ideas typed out first. Then I start over (often from scratch) and refine the ideas. I keep doing this, but re-using more and more of the ideas until I come to my final solution.