Tag Archives: philosophy

Infinite Enjoyment with Finite Resources

Have you ever thought about the miracle of music? OK, some might object to the world miracle, but I’m talking about music, something where transcendental terminology is appropriate.

On a piano you have 88 keys. Instruments can go higher (violin) or lower (organ), but with the same repeated 12-note octave everything in western music is created.

Thing about that. 12 notes, repeated over and over, at higher and lower frequencies. It’s such a small working set! How many melodies can you create in one octave?

More importantly, how many beautiful melodies can you create? Thousands of composers over thousands of years have proven that there is no limit to the originality possible with these limited tools. Of course, there are accompanying tools: instruments, rhythm, and personal style. But always with the same 12 notes.

And an infinity of beauty is possible because of it. Granted, our notions of what art is beautiful change over time, but who denies the beauty of War and Peace, Les Misérables, The Last Supper, Intermezzo from Cavelleria Rusticana, Jesu, Joy of Man’s Desiring, Pachelbel’s Canon in D, or anything by Rembrandt? Beauty grows, never shrinks.

Now imagine if there were infinite numbers of keys–how would that change things? What if we doubled the resolution of the notion of half-step (F toF#, for example) to a quarter step?* 8th step? 16th step? I don’t think this will inspire more creativity (at least not creativity that produces beautiful works of art). Too many options will spoil the landscape–clutter it up so much that not only can we not understand music produced like this, but creating it becomes onerous–there are way too many possibilities. The mathematical framework of music forces us to contain our creativity within bounds of structure that “make sense” to our minds, that allow us to understand, dissect, and enjoy.

The modern notion that lack of constraints promotes creativity is a false one. No constraints means less thought and feeling has to be put into work.

I hand you a canvas and tell you to paint your best work ever. What will you do?

You might ask–“What is the subject of the painting?” I respond–“Anything.”

You can’t work like that. Of course, you might come up with a theme yourself, but now you’re constraining yourself along a certain path.

Another example: in the 20’s Hollywood had no movie-making constraints. There were no censors. Do you remember many movies from the 20’s? In the 30’s, constraints were imposed by the government, forcing Hollywood to clean up its act. How many movies are memorable from the 30’s onward? A lot, even to my young mind. I think a case could be made that dissapearing constraints now is creating the same dull period in Hollywood that existed back in the 20’s. Sure, you can make anything you want, but who is actually going to care deeply about it?

Software development thrives under these conditions. Software developed with no or few constraints quickly looks like garbage and is much less useful. Impose coding constraints, design constraints, interface constraints–all these RULES you have to obey–and your code will become artful. Look in all the books on the subject of turning average programming into craftsmen, artists, what-you-will–the books mostly teach you RULES to follow, lines to stay within.

Coloring outside the lines is fun every so often, but you rarely frame it and call it art.

* Of course, continuous instruments such as strings can do this, but it’s not standard musical technique.

Managing Complexity – Part 2

Last time, I covered some generalities and anecdotes about minimizing complexity in my life. Today, I have a few more thoughts about complexity as it relates to software.

Software engineering has continually evolved since the inception of computer programming languages. One way of looking at that evolution is to see it in terms of improvements on complexity management. (This is a bit simplistic, since computers have simultaneously become much more complex.)

The first computers were simple by today’s standards, but the programming methodology was very complex: dials, levers, buttons, or physically connecting wires. Then machine language was developed binary code could be entered on a card, later memory, and interpreted.

These early languages required a perfect familiarity with the machine. If the machine changed, the code changed.

Over the years, the advances in languages have largely been a process of hiding the machine’s underlying complexity. ALGOL came around and hid the machine code and provided the foundation for FORTRAN and C. C built further by providing both structured programming tools and an abstraction of the machine’s language–one foot in each world.

Terminals began to have graphics capabilities and SmallTalk was developed to further hide the complexities of both growing code modules and user interface elements. Java hid the complexities of lower-level code like C and C++, and even took away the concept of a physical machine and substituted its own virtual machine, theoretically consistent across all physical platforms. C# has done much the same for Window–hiding the complexity of thousands of APIs in a hierarchical, intuitive framework of managed code.

Modern processors are beasts of infinite complexity and power compared to the early hulking iron giants, but the languages which we use hide nearly all of the complexity that our forebearers had to deal with on a daily basis.

Now it looks I’ve been really writing about abstraction. It’s extremely strongly related, but I don’t think it’s exactly the same thing. Abstraction is thinking at a higher level; minimizing complexity is thinking less.

Modern languages both abstract away lower level concerns and provide tools to minimize the complexity of things at the highest level.

There is increasingly a proliferation of visual tools, begun with GUI editors, but now including visual code designers.
Aspect-oriented programming and attributes are allowing complexity to be further minimized.

In the future, tools such as these, and increased use of COTS will become vital to accomplishing anything. Software complexity will only increase, but hopefully the trend of tools that minimize complexity will also continue.

Perhaps somebody (not me!) should investiage the theory of a total complexity quotient–a measure of the complexity of a system and the complexity of the tools to develop and manage that system. With this number we could measure if complexity overall is increasing or decreasing, and what/when is the crossover point.

Managing Complexity

Software engineers know that one of the keys to achieving development goals is effective complexity management. The single best way of managing complexity is to remove it from the system completely.

As a simple example, in an earlier version of my BRayTracer project (I really need to come up with a better name!), scene objects were edited by double-clicking on them in the tree view, which opened up a dialog window that displayed the properties of the scene object. The user could make changes and then click OK or Cancel.

This data flow introduced complexity by requiring:

  • An additional window to manage
  • Moving data between the main window and the dialog
  • Making a copy of the scene object
  • Allowing the user to cancel or undo previous actions

The functionality of being able to cancel changes necessitated most of that complexity.

While this example wasn’t overly complex, I still felt there was a better, simpler way. You can probably see a number of possible solutions:

  1. Implement a general undo system (more complexity)
  2. Don’t allow users to cancel changes–they’re committed! (possible, but wise?)
  3. Eliminate the dialog by having a child window on the main form (does not allow cancelling, but removes the additional dialog)
  4. Rethink how objects are edited from the ground up (expensive)

I went with option 3. Obviously, there’s a tradeoff here. I sacrificed some functionality for the sake of simplifying the interface and the code. In fact, in usability testing, many users wanted a way to cancel or undo changes. Someday, I’ll have to go back and add a way of doing it. This illustrates the principle that sometimes complexity is unavoidable for certain features (Undo support, for example, is nearly always very complex to implement effectively) and that often what is really going on is shifting the burden of complexity somewhere else.

Minimization of complexity is also tightly coupled to the principle of optimality (ah…but optimality of what?).

The tendency of developers (at least I assume it’s a tendency–I am, of course, generalizing from my own experience and those people I’ve observed) to minimize complexity is something that can carry over to our normal lives. I notice this myself in a number of ways, most of which probably aggravate Leticia to no end 🙂

  • When driving, I almost aways get in the “optimum” lane as soon as possible, that is, the lane from which I’ll have to make the fewest changes. Changing lanes adds to complexity. Having to worry about changing lanes when it becomes crucial adds too much complexity. While there are exceptions for painfully slow people, I change lanes only about 6 times on my 35 mile commute (4 roads and 4 highways).
  • When I cook, everything is optimized for minimal disruption. All ingredients and equipment are pregathered and then prepared in a way which minimizes work, time, and coordination.
  • When I watch movies at home, I try to optimize the experience by first queing up the movie, setting up the environment, volume, and then making popcorn. That way, once the popcorn is done we can begin watching immediately, while it’s hot. I almost can’t watch a movie without popcorn.