Pieces

Pieces, the separate parts of a whole, help us understand the logical process of construction. The relationship between the pieces, such as how well they fit, help us understand the workings and character of the parts. The individual pieces limitations can bear on the capabilities of the finished product.

A cohesive design is almost always made up of separate pieces.

In a good design there are no inessential pieces: each piece is necessary for the design to be complete. Each piece does what it should and also as much as it can do.

Interrelationships Between Pieces

Also, the relationship between the pieces is key. In organization, there are requirements for one department that are produced by another department. In development, one module produces a result that is used by one or more other modules. In three-dimensional objects, the objects can fit together like a dovetail joint.

In a drawing, the pieces can be shaded to fully reveal their form. They can shadow other pieces to show their inter-positioning. When you see a drawing, it can make you think about how the figures in the drawing are placed, and what message is intended by the artist. In a still-life this may be of little consequence. In an Adoration of the Magi, this can be of great consequence.

Cycles

The interconnection of pieces can be cyclic, producing an induction. This cycle should be essential to the concept of the design. In programming, the loop should be essential to the working of the program, an iteration that converges on a desired result.

In a drawing, the interrelationship becomes essential to the piece as well, as indicated by this impossible triangle, copied loosely from Oscar Reutersvärd, the Swedish artist. Sometimes we can highlight something different than what was originally intended, as in this case: we indicate how the figure can be made of three L-bends that mutually depend upon each other. Impossible figures often make an excellent illustration of cyclic structures.

Also, though, looking at cycles in different ways can reveal to us more about the problem than we originally knew.

Development In Pieces

In development, we first conceive of a problem to solve and then sketch out a structure of how we will solve it. Then it helps to divide the problem into pieces. It suits us best if each piece is well-defined. We know its inputs, its results, and how it will produce them. When a piece is too complex, we can divide it up into smaller pieces.

The nature of each piece can then be worked on individually. Either sequentially by one person, or concurrently by multiple people in a workgroup. Because each piece of the problem has a different nature, this lends itself to specialization, which is suited to modern workgroups. Each piece can then be tracked separately. The interrelationship between the pieces will need to be known by the manager to properly chart the progress of the development.

Most large projects are done this way. When they are done by one person, then that person needs to understand the workings of the project as a whole, and this can lead to a huge, unmanageable situation. But not always. When a problem gets too large for one person, the pieces of the problem lend themselves to adding extra people to help, and so project division is essential to minimizing unpredictable schedules.

When Pieces Fail To Connect

When conceptualizing the division of a project into pieces, it is sometimes not possible to foresee each and every wrinkle in the workings of each of the pieces. This can lead to a situation where a piece can not be constructed or where some pieces can't be connected properly.

It is times like these when it's important to stand back, take stock of what you have learned, and integrate that into the design. Sometimes this necessitates a redivision of the project into new pieces. Sometimes the redivision only affects a few neighboring pieces. This is part of the art of project design.

Development Strategies

The pieces of a project represent the result of top-down decomposition, which usually works as a division process. Once you have a project split into pieces, and the pieces implemented, then it becomes a problem of making sure that each piece works as it should.

This entails isolation of the piece, testing its inputs, and validating its results.

In a workable system, it is essential to be able to view the intermediate results of each piece. In a graphics system, this means literally viewing them on a screen to visually verify that the result is correct. And sometimes, the ability to view each minute detail is also required.

In a system that is constructed in pieces, one problem which is presented to the authors is this: how can we add a new feature or behavior to the project. This is important because usually it is necessary to construct a simplified version of the project and then make it more complex, adding features, until it is complete.

A useful capability is this: build a simplified version of a piece for testing with the other pieces. Then, each developer can work with the entire project and flesh out their piece independently. Or, even better, a new version of the piece can be checked in, adding essential capabilities, while more complex behavior gets worked on independently.

Performing the Division

I mentioned top-down decomposition as a useful tool in dividing up a project into pieces. But this must be tempered with other considerations. For instance, the necessity that each piece do exactly what it needs to do, no more and no less. Another example is the requirement that the inner loops be as simple as possible, necessitating the factoring of extraneous and more complex cases out. This means that the subdivision must be judicious, to achieve local economy within each piece. I have been on many projects where this goal was a critical factor in deciding how to divide the problem up into pieces. This can also serve as a razor which cuts away inessential parts, leaving only a minimal interconnection of pieces.

You also want to make sure the project is organized so that, if a piece fails, we can directly verify this by turning it on and off, and seeing the result of its action and the effect of it on the entire result. This is particularly useful when each piece is a pass of the total process, like in a graphical problem, or in a compiler.

Also, it is useful to construct a test harness that contains UI so that each piece can be independently controlled, preferably with real-time adjustment. This is a great way to exercise the project. I have used this many times.

Taking Stuff Apart

Moving from development to three-dimensional construction, the disassembly process can reveal a tremendous amount about the problems encountered in producing the object, device, or mechanism. When I was a kid, I liked to take things apart. Of course, putting them back together took a bit longer.

In modern times, there are entire companies that specialize in taking gadgets apart, and even slicing open chips to reveal their inner workings. This is the process of reverse-engineering. Examples of companies that do this are chipworks.com and iSuppli.

Gadgets

I was going do do a section on gadgets and the pieces thereof, but I realized that my knowledge of such things is really not up for grabs, nor is it for public consumption.

It's really too bad since gadgets are a classic example of how each part needs to do as much as possible with as few resources as can be spared. This is one of the basic design decisions that govern the division of a project.

Often the most remote considerations suddenly become of primary importance in the division process.

Code

A friend wishes to divide up code in such a way that module authorship can be retained and the usage monitored so royalties can trickle in the proper way back to the source. Very distributed-economy. This reminds me of the App market in a way, and I'll tell you why.

In early days of software, there was much custom software that cost huge amounts of money. There were accounting systems and mainframes. These would often cost a hundred thousand dollars. The CAD systems I worked on in the 70s were very expensive as well, and specialized software, such as all-angle fracturing software, could cost plenty. It's funny how big business still maintains this model, with distributed systems still costing lots of money. This will certainly be replaced by a distributed app-based model. Some believe that the gadgets are only the front end to a giant database. This model will be replaced by the cloud model.

In the 80s, personal computers' penetration increased and software became a commodity that was sold on the shelves of computer stores. This drove the average price down to hundreds of dollars, but some software still could command up to a thousand dollars. Consider Photoshop and the huge bundles of software that have become the Creative Suite. As time went by, lots of software was forced into bundles in what I call shovelware: software that comes with too much extraneous stuff in it, to convince the buyer that it is a wonderful deal. I'm thinking of Corel Draw! in those days. Nowadays, sometimes computers are bundled with crapware, which is the descendent of shovelware.

The commoditization of software was just a step in the progress of applications. Now, applications are sold online for the most part, even with over-the-air delivery. This is because much computing has gone mobile and desktop usage is on the decrease. Many desktops have in fact been replaced by laptops, which was one step in the process.

But the eventual result was that software is now sold for a buck and the market has consequently been widened to nearly everyone.

To do this, the software had to become easier. The model for the use of the software had to become easier. The usefulness of an application had to become almost universal for this to occur and for applications to become more finely grained. Apps now sell for anywhere from free to ten bucks. But on the average, perhaps a complex app will cost a piddling two dollars.

Is it realistic for the remuneration of code authorship to also go into the fine-grained direction from the current vanguard of open-source software? Nowadays, many app authors receive royalties for their work. The market for applications has exploded and the number of app designers has also exploded: widely viewed as the democratization of programming. This is the stirring story of how app development penetrated the largest relevant market. Can the programmers themselves become democratized?

The applications of today live in a rich encomium of capabilities that include cameras, GPS, magnetic sensor, accelerometers, gyros, and so much more. For code itself to go down a democratization path, I expect that the API it lives under will have to be just as rich.

Unfortunately, the API is owned by the platforms. And even, as in the case of Java (as we have found out this last week), by the company that bought it (Oracle). Apparently an API can be copyrighted, which is a sticky wicket for Google. The vast majority of apps are written for iOS today. But, if this won't be true forever, then at least it has clearly indicated how to create an incredibly successful business model around applications. And it indicates that APIs will certainly be heavily guarded and controlled.

The spread of technology is never as simple as entropy and thermodynamics, though the concepts may certainly bear on the most profitable use case.

Either way, the democratization of code could possibly solve the litigation problem, at least when it comes to applications built on top of APIs, because the new model might in some sense replace the patent model by reducing ownership to a revenue stream, democratizing software developers. But the APIs could not be a part of this solution as long as the platform developers considered them to be proprietary.

So, in the end, I don't think system software can be a client for this model. Unless its the GNU folks.

Style and the Digital Era

Before there was Painter, what was my style like? Did Painter change my style? Or did it just extend it into new media?

When I was young, I was obsessive at drawing. And, as you can see with this self-portrait, done when I was 19 or so, I had considerably more hair. And this as my look: a white button-down shirt with a collar, photo-gray glasses, a mustache, and near-shoulder-length hair. For a nerd, I was a bit cooler than most. This was drawn using a photograph as a reference, and you can see my left eye opened a bit wider than my right eye. It still does.

My obsession with drawing became valuable to me as I moved onto the computer. When I was 25, I developed my first paint program. This was at Tricad, a company that made computer-aided design (CAD) workstations for architects, engineers, and construction. It was doomed to failure because only a few years later all that kind of work was destined to be done on PCs and not VAXs.

But, in those years, I had access to frame buffers and raster displays that allowed me to start working on paint. Five years later, that business had failed (I wasn't running it) and I had joined with Tom Hedges in our partnership, Fractal Software. That was when I created ImageStudio, my second paint program. ColorStudio, created a few years later, was my third. Although Tom was the lead programmer on ColorStudio, I was responsible for all the painting and color primitives. So I was the artistic side, and Tom was the systems architecture side.

One and a half years after that, I started work on Painter, my fourth paint program. That one persists to this day, and I am proud of it. Corel sells Painter 12, currently. But the main reason I created it in the first place was so that my drawing talents could migrate onto the computer. I knew it wasn't going to happen overnight.

I was into landscapes, fantasy intertwinings, three-dimensional visualizations, positive and negative space, and so many other things before I ever got into computers.

Here is a sketch for a planned painting I was doing. There are mountain ranges, valleys, and rivers. There is a planned cloudscape with swirling and directions, indicated by arrows. The foreground of the scene is intended to be a terrain ledge, a vantage point. Click to zoom in. The location of the sun and its effects are made plain.

When this transferred into Painter, there were initial limitations with the medium. The works I did were sketches that were smudged around using Painter's Just Add Water tool. But I did do quite a bit of sketching with the Wacom tablet and using pencils in Painter as well.

It is funny. My art became the first Painter screen shots that were distributed to the press. I considered them naive, but they were all I had to offer at the moment, as I improved relentlessly on Painter's capabilities. You can see my style come through, although the hand-drawn traditional art was certainly more complex.

Another bit of art from my younger days, perhaps in 1975, was done in an EBONY pencil on plain old cotton bond. I liked my paper to have a little bit of grain so I could get the extra high density and therefore the high contrast. You see a stream with a stone in it.

The main things to look at are the reflections and the shading. You can see the unfinished hills in the back where I hadn't yet applied the shading. There is an overall shadowing in the stream that is shown as a swath of darker shading towards the right bank.

The way I portrayed light and shadow was something that did translate into my painter work.

Here, a rough sketch for a paint can is dated in 1991, when Painter was being finished. The reflection of the can can be seen, and it shows a similar kind of attention to shadows and reflections. The background is shaded just for the sake of having texture. One thing that interested me was using the eraser in Painter to create negative shading: highlights.

Artists used to use silverpoint and also white charcoal to create highlights in their drawings. I used the density eraser to achieve similar effects without just creating white streaks.

So my drawing style had to adapt to the new tools I created in Painter. The arrival of John Derry at Fractal Design led to the creation of the Wet Lab, a place for exploring traditional media and studying both their effects and the manner in which traditional artists use them. In the Wet Lab, we explored scratchboard, silk screen, acrylic paint, airbrush, and many other tools.

I found scratchboard to be very satisfying indeed, and I used it to explore my preference for positive and negative space in a new way.

Here, in the very first scratchboard piece I ever did, you can see the scratching away of the black ink layer, leaving the white enamel layer. I worked on perfecting the light strokes and also the overlaying of strokes. At the bottom right is a gradation using hatching that I experimented with.

While drawing in scratchboard was initially, for me, just a way to draw in negative, I eventually got into finding ways to surround dark objects and define their edges.

This is a follow-up piece with the cat. My black cat at the time was named Cheshire, and he was a bit scruffy. Cheshire had the habit of defending his territory. Once, Tom Hedges with his (then) wife Caroline, came to our house and entered with their dog. Pokey (kind of a pathetic name for a full-size German Shepherd) was immediately cowed into the corner by the door by a very aggressive Cheshire. We found it hilarious.

Cheshire the fearless cat!

So here we have 3-dimensional form, perspective, and just enough light and shadow to make it convincing. I was always looking for ways to increase the number of levels of any image I worked on. I quickly decided that scratchboard required a lot of planning, due to its write-once nature.

Once we finished the scratchboard tool, it became a part of the new toolset for Painter 2.0. This attracted some new artists to the Painter stable, including the fabulous Chet Phillips. It seems scratchboard and watercolor were wonderful to use together. I guess Painter, with undo and easy re-inking, became a much easier way to create scratchboard.

My earlier art often had high-contrast figures, but they were almost always dark-on-light. I had to turn my brain around to make scratchboard work.

Here you see some of my more hard-edged work. This one is from 1978 and shows me at a Hazeltine Honeybee terminal (which had amber letters on a black screen) with a listing opened beside me on the table.

A single hanging incandescent bulb lights the scene, in harsh light.

There was no mouse in those days, just a keyboard. But there were mouse holes, it appears!

While defining positive and negative space were part of my style in one way, they also were in another. Often I would draw with lines instead of areas. And the negative space would simply be constructed in 3D. Then the negative space would appear as real holes in 3D objects, or niches that were carved out of them

For instance, I could start with a cube and take away sections of it, like knocking away cubes in minecraft.

Then maybe I could make something new from the leftover cubes. In this case a symmetric pattern is etched out of a cube, and a rotationally-symmetric pattern surrounds another cube, with some rectangular "pipes" passing through the center of it in three different directions. Unlike with scratchboard, I could erase pencil marks when necessary. This made it easier to explore the possibilities. Perhaps that's why Painter got undo!

Roads, tunnels, spires, bridges, and upside-down mountains might describe this piece, although it is named "city". The tunnels are the negative space. There are also holes and even a keyhole.

The upside-down mountains are just another one of my signatures: looking for different directions. Freeing myself from physical limitations.

Drawing doesn't have to be literal, and that is its advantage.

With Painter, the line drawing seemed to no longer be my concern. Instead I dwelt on shape and shading. So the line drawing was just the medium. And Painter, with lots more media, became a place to explore. It enabled me to try new things.

In a similar vein, this wild image shows that forms are plastic and interchangeable with human features.

Note the dark clouds at the top. I loved to create rounded shading. But I knew that they would look even better with catchlights on their edge: the silver lining.

Note next the windows in the leaning building. They are specifically designed to not be straight.

A shaded skyline is visible in the background. And there is also another one, upside-down at the bottom.

Another stylistic signature feature was the water drop. At the lower left, below the tongue, are some drops. Below them are buildings that just appear to be blocks in space, disjointed and floating.

Holes appear as negative space, and often the roads find them.

In Painter in 1991, some similar stylistic points appear in this piece that was used for so many press kits and was used for the original announcement of Painter in MacWeek, when Connie Guglielmo first wrote us up.

You see the clouds (this time with catchlights, courtesy of airbrush and frisket) at the top. Also, you see the water droplets (this time transparent, also tanks to airbrush and frisket).

Painter's tools provided me more depth in this way, allowing me to express my style in new and different ways. But you can see that some of the complexity is gone. It was early, folks!

Some elements of my early style went beyond positive and negative space, and traveled into the domain of the impossible.

This image, "inside/outside", shows the dual nature of inside and outside.

The last image (found below) is called "many views", and it shows the join in of a water hose with a landscape, and then finally with a scroll of paper. Shapes, shading, and knots adorn it. It can be viewed, like so many other of my early images, both right-side-up and upside-down.

I'm glad I got a chance to make Painter. It taught me a few things. And it set me on a journey to meet great artists, find friends, and expand my style. And at least some of the stylistic expression of the hairy 19-year-old me came through.

Three-Dimensional Thinking

I have never seemed to have any problem thinking in 3D. What should you look for in kids that are good at this? Perhaps I can give a few pointers.

Back in 1968 I was tested for intelligence and they told me I scored very high on visual-spatial processing. This was no surprise to me, because I was always making things. I made geodesic domes, for instance, using some Buckminster Fuller designs I found in a library. I was always drawing objects, working them out in 3D, learning how to shade them, or to draw shadows.

Other kids thought I was a bit different. And I guess they were right. I constantly drew in class, much to the chagrin of my teachers. The drawing was a useful talent when it came to such courses as geometry and art. But it did cost me some grades in history and English. Fortunately the spatial reasoning helped connect me to mathematics and I also found I had a head for numbers and symbol processing. I guess that's why I ended up a programmer.

My early drawings were simplistic, but that soon changed to the fantastic. By the time I was in high school, my drawings were simply out there.

Take, for example, this drawing of roads intertwining. Some roads can be seen spiraling. Or the lines on the road can be seen coming off into space. Or merging.

My favorite illusion is the lines on the road becoming a thing unto themselves and floating in space. Even casting shadows.

My point is, if you see a kid drawing this kind of stuff, you might want to encourage it. Or at least try to understand what it is getting at.

In my case, my brain just wanted to make something interesting. The real world was kind of boring compared to what the imagination can provide.

The holes are interesting too. They represent negative space, and provide some contrast.

For me, eventually, fantasy generally gave way to impossibility. Impossible figures were the rage when I was a kid, and I turned it into a science. For instance, in this small sketch, It becomes important to me to generate the most convincing illusion, or to provide a "correct" interpretation of the impossible figure.

But even impossible figures can lead to wild speculation of interweaving. This image, done on light aqua paper, was actually more a design than a convincing illusion.

So really it's more of an intellectual exercise. And its triangular clipped format makes it even more of an art piece.

All this was actually done without grid paper of any kind. Rather, I relied upon a ruler, a protractor, and a pencil. And I did have to erase some of my construction lines.

Hey, nobody's perfect!

But I did buy some grid paper, that was designed for gaming. This was hexagonal grid paper that gamers used to design their worlds. I found such games tedious. In Caltech, several people "disappeared" into the game Dungeons and Dragons. And they were never heard from again. So I was wary of that obsession, and you should be too, when it comes to your kids.

Still, minecraft is an excellent game for teaching spatial reasoning.

In this image, the hexagonal paper is used to create a fractal-like pattern. Really, it's closer to a space-filling curve. It's an example of the kind of fun I had in the 1980s.

The colors were simply drawn in with a set of felt pens. I don't think I have used the minimum number of colors. As we all know, four should suffice.

But back in 1978, I was interested in meshes long before I did any 3D programming.

Shown on this yellow note paper sheet is a mesh construction of a face, a Hamiltonian unwrapping of a dodecahedron, and a picture of a dodecahedron (at the bottom) which has been stretched.

In the center is a rhombic dodecahedron constructed around a nesting cube, which can barely be made out.

To the left is a Hamltonian unwrapping of the same rhombic dodecahedron.

The notes are simply device addresses on a VAX 11-780, I think. Good times!

Even better was a paper-folding project I did for no particular reason. Perhaps it was for a fold-out birthday card. I simply can't remember now.

Here are my sketched plans for it. It appears to be a corner-nested construction made of cubes. This should be familiar to any minecraft user.

Below it I have figured out how it can be folded flat (and this is one of the more interesting tasks that might be used to test spatial reasoning).

You cut the horizontal lines, and fold on the vertical lines to create the result. I was proud enough to save an actual example of the final product, which I unfolded and photographed.

So you can see the result of my labors to the left. Yes, there is a little creasing in the paper, but it has been folded flat for many years.

Actually I was kind of surprised it has survived.

And for my final trick, I have my self-portrait with copy machine. That's me at 16 or so. Probably about the time I went to UC Berkeley on the National Science Foundation seminar. And met Professor Lehmer. And got tear-gassed in a demonstration near the campus. And had to duck into Harry's Hofbrau. Where I was served a beer. But that's a story for another day.