A few months ago, I tried my hand at making a graphic. I picked Paint.net (Gimp just isn't a "together" app for a newb, sorry) and a simple enough project: I would create the title graphic for my yet-to-see-light-of-day personal website exactly the same as this site's. The subdued look and the sunken text jived with my sensibilities and I wanted to learn to create that effect all by myself.

Paint.net has a very active community and soon I found a simple enough guide to do what I wanted. I followed the steps and was able to recreate the graphic - almost. The difference was that the guide assumed a fixed background and I wanted the effect to work regardless of the background color. The only way to do this is to make the background use the "invisible" color - which was helpfully available in another guide. Thus began an long series of minor tweaks to combine the two guides' advice and result in a graphic that looked "just right".

Graphic design (I know this term has a larger meaning, bear with me) essentially follows the Painters Algorithm. Layer after layer of paint (pixels) are placed in an exact order so that the resultant graphic will serve its purpose from exactly one angle - the one that the graphic is intended to be viewed from. True, software allows for easy undo and redo of these layers and the easy (and gratuitous) application of effects, but there's little difference in principle between this activity and hand-drawing.

More over, the raw material being molded into final shape is nothing bigger than a pixel. Well, maybe groups of pixels via Lassos and Layers, but pixels nonetheless. The basic idea seems to be: corral a bunch of pixels and subject them to an effect. Repeat corralling and effect-subjecting till desired result is attained.

Contrast this with 3D rendering where the raw materials are shapes, their properties (especially texture), the light sources that impinge on them and so forth. The mental model is straightforward because the representation is real-wordly and - this is crucial - a 2D projection of the object(s) can be taken at will to represent any POV. This projection is essentially the same as the Painter's Algorithm - rendering it requires calculating planes (layers) that lay in front of others and therefore don't need to be displayed.

Except that we have a computer doing it for us; we don't have to painstakingly figure all that out by hand.

Reflecting on this in a slightly grander scale led me to think:

...Are we painting our code or rendering it?

My team is currently trying to refactor some code. The code is about a page and a half long and was written about a month ago. It has unit, component and integration tests attached to it. Yet the original author (quite a bright chap) is unable to figure his own code out. He knows that it works and knows that it will break unless its written exactly the way it is. Beyond that, however, he's unable to explain why it works the way it does; or - more importantly - explain the logic succinctly such that the "why" could be remembered. If we had to introduce a change into the logic, that would be flagged as a "major enhancement". Here's the other twist: The code is in the critical path of 7-8 business scenarios and therefore has to be tested for all those scenarios ; but being path-agnostic in and of itself, that fact is not readily apparent from looking at the code at all!

I begin to wonder therefore: Does the shape of the code reflect the shape of the real world thing it is attempting to represent?

Another example: I just finished reading Kent Beck's post on Horizontal and Vertical Refactoring; and what struck me is the recognition of the idea that code could have more dimensions than one.

Better tools for a better age

... but after a while all is see are blondes and brunettes


(the argument that the expert doesn't need the UI)
visual vs higher order
- finally circle back to "painting has its place, just not in mainstream sw dev"