Friday, June 29, 2012

Programming experience changes the sense of beauty

I had a chat with a guy today who hates things that have no intrinsic meaning.
Say we have a directory structure like

episode - sequence - shot

and shot dependent files are under the 'shot' directory.
(I'm sure this structure is familiar with you if you are working in a vfx studio)

When we want a directory to put data that are common to all the shots in an episode. We can think of two directory structures for the purpose.

episode - sequence - shot
               - common

episode - sequence - shot
               - common   - common

The latter has two directories named "common". Outer "common" always has only one directory: inner "common". So essentially it's enough if we have only one common directory like the former example. Having two commons are redundant and it can make people feel intuitively ugly. But in real life creating two directory has a good meaning - if we have two commons, we can always assume there are three directories, one for episode, one for sequence, and one for shot. This assumption simplifies making tools a lot. It slows down directory access a little bit, slightly increases disk usage and traffic, but in most cases you can ignore them. It will also make you irritated if you access to common files manually, e.g. with windows explorer, but it is usually wrapped up by tools and it should be, so there's no drawback in that sense as well.

In general, it is better if there are smaller number of rules while making things well defined (i.e. not like, "we have everything in 'any data' direcotry".  In the above example "common" direcotry should have well defined sub-directory). As you start getting used to programming, you become finding simplicity more beautiful, and you starts understanding that removing simplicity just for removing redundancy has no sense because it means sacrificing functional beauty just for visual appearance.


Jun 30 added:

Good generalization and bad generalization. Good generalization makes you extend functionality easily,  bad generalization puzzles you with lack of information on what data it is about. If you have a fully generalized structure (directory structure, framework structure,  work flow structure etc.) and well defined layer on top of it based on your demand, you can prevent having 'any data' stuffs that all you know about is creation date, and the structure still has room for future extensibility.

1 comment:

Cristeen said...

fantastic post and Thanks for sharing this info. It's very helpful.
web agency brussels