October 07, 2006

"Software as a floor mosaic" metaphor

Here is a "software as a floor mosaic" metaphor: let's say we need to inlay a floor mosaic. We have a sketch or may be even a highly detailed plan of how the thing has to look like, and even the vision of it and clear and perfect, something like this:

We also have at our disposal assorted pieces of stone, ceramic patches, coloured sand and all the tools we might need. But no matter what tools do we have, it takes experience and above that a lot of time to make such a mosaic. Yes, experience helps but we still need to take each piece, adjust it, finish it and put it in place. Sometimes the piece will crack in our hands and we have to start over. Sometimes, a piece will be very different from what's needed in that particular spot and require much more work than another.

But then there is time pressure - the worst of all curses. Pressed with time we have the following alternative: to make it faster, we might take bigger stones and throw them in quickly yielding something like this:

And it may even sort of look similar, but I just can't force myself to see the plan in the implementation. Aesthetically, at least, it's obvious that mosaic laid out in this fashion is no match to the envisioned one. But how did our big stone practice made it break ?

In other words, what can we say about big stone mosaics ?


Bigger stones are by definition fewer, so we have to invest less in learning. The less stones we have to learn how to deal with, the more confidence we have in that we know how to handle them properly.

There is less variance between big stones, consequently there is no choice as to which stone pick for this or that spot - one less burdening decision to make.

Takes fewer pieces to lay the mosaic out. And it saves time, this is precisely the reason we choose this way.

The less pieces, the less interaction between pieces (although I must admit, this is really more a software insight).


UGLY. There are situations in which big stones fit in precisely, but those are exceptions, rather than rules. If we are up to a piece of art, not to the standard kitchen tile. This is the aesthetics-breaking reason. This is why the first one is amazing and the second one is not even satisfactory.

Along the same lines of aesthetics and taste goes this - if someone is always doing big stones, how could she tell what's beautiful and what's not ? It's still a mosaic, isn't it ?

Bigger stones obviously not always fit and we have no control over it. If we want control after all, we need to apply much more work compared to what would have needed if we were combining smaller ones from the start (that's exactly the reason why mosaic exists - we take small patches and combine them in a such a way that the whole thing looks beautiful from some distance, and don't spend forever cutting).

A mosaic built of bigger stones is less reliable (alhtough again, it's more of a software insight). We may be confident, but there is no way we can tell a crack inside a big stone, and if it happens to exist, we have no control.

And so, what's the average stone size modern software mosaics are being built of, what do you think ?


Anonymous said...

Analogies are where you take two things that have no relation whatsoever (e.g. stone mosaics and computer software), and demonstrate a similarity of form rather than content. As far as content goes, mosaics and software are in two different worlds. As far as form is concerned, they are similar in as much as they both have a lot of parts and the whole is more than the sum of its parts. But then again, that means you could have compared software to a car engine, or building architecture, etc.

"Parts" in software are usually comprised of other sub-parts or inherit multiple parts or do something to other parts or even become other parts. Mosaic stones don't do any of those things. Mosaics are inherently flat layouts where stones are used like ancient monitor pixels. In itself, the number of components or their size doesn't say much about software quality. Coding software is more similar to language-as-art such as prose or poetry than mosaic art.

The point? If I write an FTP server in Python or C++ or even BASIC, if it works the same from the user's point of view (the mosaic viewer), then it doesn't matter how big the components are. In programming, rather than real-life mosaics, sometimes the big stone mosaic is the small stone mosaic. Language and component choice depend upon project goals.

Dmitry Dvoinikov said...

You have a set of very good points there.

Indeed, there is no recursiveness in mosaics, on the other hand, in software development, you almost never treat your components as though they had any structure to themselves, on the contrary, you see them as an individual stones with certain external properties. It's like they are just given, much like stones, and all you have to do is to put them in the right spot.

I would also to add that if a user sees no difference in mosaic internals, he must be so very far from it, or his view be totally obscured, which defeats the entire purpose of the mosaic. In fact I was talking more about a developer's point of view - the one who is actually entitled to evaluate the structure of the thing.

parquet floor said...

The undeniable beauty of parquet flooring is financially out of reach for many people. A cost comparison between replacing the old worn out wall to wall carpeting and installing parquet flooring will show that the parquet choice is less expensive if you install it yourself.

If you don't have sub flooring which can be sanded and varnished, you might consider do it yourself parquet flooring. Eight or twelve inch squares of finished oak are available in several shades of stain from dark walnut like oak to pale natural tones. The wood grain is preserved in all finishes and the final clear coat will stand up to most traffic.