Wednesday, July 18, 2007

Showing Constraint

No one likes to feel constrained. This is doubly (triply? n-ply?) true for programmers - our fingers clutching, addicted... no, scratch that... bound to the concept of control like some malaise-powered adhesive. Like the old phreak claimed: control is what lured us to computers in the first place - preferring instead to dance freely amongst the fields of digital powers and fresh cyphers - free from the worries of average humans, like money, or sleep, or hygiene. I can think of no commodity higher on the curve of our collective priorities than freedom, of various sorts. It should come as no surprise to anyone that constraint cuts through us like bolt-cutters. But constraint can be useful - and in some cases self constraint is powerful. Limitation can be liberating. It is this irrational fear of constraint I wish to address - specifically around the idea that Maven's conventions are stifling - and that a reduction of choices is necessarily a bad thing (it's not).

Anyone who knows me well enough knows that Dan Dennett is my third favorite western philosopher (Quine and Heidegger are one and two - fwiw). I bring him up because his description of the Library of Babel is a good preamble to my point (he did not create the example, but only its usage as an illustration of Vast possibilities - the original Library was described by the Argentine writer Jorge Luis Borges). In short, the Library of Babel is a library containing all possible books. For simplicity, he argued, let us limit our library to an alphabet of 100 characters - further simplified, we limit each book to 500 pages. Smaller books can be bundled between the covers of a single bound book - whereas larger books - like the Bible or anything by James Michener - would be spread across several volumes. Every book written or conceivable would exist here - even a book about your life, or every possible variation of your life. He spoke of Moby Dick, for example, of which there is an entire branch in the library containing slightly misprinted versions of the book, but all recognizable as Moby Dick. There are 200,000 versions (one for each word) containing the complete version - but with one word replaced by "jack" (Such with the opening line "Call me Jack", but otherwise the exact book) - another 200,000 with with one word replaced by "hat" or "worbble". Then the untold modifications around punctuation (Call me, Ishmael) or single character typos of every combination, and then of course multiples of these, and so on. Let us not forget the book translated in various languages and all of their variations. We could hop in a space-ship and fly through the galaxy-size Moby Dick section and never hope to glimpse them all. Since we have every possible book combination our library is not just relegated to books - but computer programs, detailed descriptions of paintings, and even genetic code.

Importantly, though, this library is not infinite (we know that since - with only 100 characters and 500 pages - we can certainly calculate a finite set of possibilities) but it is indeed Vast - so vast that the "V" is capitalized to reinforce how Vastly, ginormously, inconceivably huge it is (for those who just have to do the math: assuming a space is a legal character and all books are of similar typography - let's say 100 characters per line, 50 lines per page, and 500 pages, that gives us 10 to the power of 25,000,000 - 10 followed by 25 million zeros - unique book combinations - which of course themselves can be combined in a cartesian product of ways. In short: lots). Despite the vast number of intelligible books - there will be a further Vast number that are complete gibberish. Although many Moby Dicks can be called "correct", even those that exist in other languages, far more will contain nothing more than the correct opening line followed by pages of babble. True, we can always invent languages to make sense of these "gibberish" books - but the important thing to note is that the book combinations themselves are finite. The possibilities are not infinite - but they are Vast. The number of possibilities that can make sense to us as humans are very very small by comparison, but the number is still huge - far too huge for our Vanishingly small brains to comprehend.

We know that there are a Vast number of design possibilities - but what does this have to do with constraint? Everything. Considering the number of book combinations that are almost Moby Dick you could spend the collective lifetimes of several planets filled with authors writing Moby Dick variations, as well as books about and inspired by it and about it. And here is the point: despite our weird Moby Dick constraint - there are more than enough variants of that one book to last several careers. Being constrained does not tie hands as many of us might fear. Consider an example of art. Pablo Picasso, through his self-imposed constraint to the cubist style, created some of the worlds greatest works of art. William Shakespeare was constrained to iambic pentameter in his plays, but few would argue that it stifled his creativity. Style is a constraint that greatly narrows our choices - but frees us to focus on the important points.

Programming a computer, like writing a book, is one of the Vast number of possible combinations for each language. Luckily for us, useful code combinations are narrower (if they were not we'd just generate them and we'd all be out of the job), and narrower still when we consider other constraints: the ability to communicate over a strict network protocol, APIs, user expectations, accepted conventions. Being thrown into a world of possible designs with no constraint is filled with a maddening number of choices (most of which are dead-ends - or gibberish) - constraints reduce the time spent thrashing on a problem. That is all education is for, really, to constrain your thinking into a narrow, accepted path, out of the field of all possible paths. This is not to say that the path is so narrow as to remove all creativity - far from it - for the realm of possibilities is still massive - as shown by the throngs of creative, yet educated, people. Few programmers enjoy writing their own device drivers to interact with their own custom keyboards, nor want to first write a custom programming language by way to program. These are not only largely solved problems (and make inter communication with others difficult), but they also detract from more interesting - and more creative - endeavors. Not many cartoonists create their own paper, nor many musicians create their own instruments. Such tasks distract from their ultimate goal: self expression. When people complain about the constraint of a style it is - very often - rather a complaint about the efforts of education, and the efforts of mastery. Poetry without form more often emerges from laziness than a learned reaction against a perceived inferior convention or attempt at breaking new ground: "Meters are hard, rhyming is hard - I'll try stream of consciousness".

Finally we come to the part concerning Maven: there is nothing to fear from the constraints composed by Maven on project structure. Though the conventions are overriddable, it takes discipline to avoid it. I will not delve into the communication benefits of Maven here, but rephrase the above thesis: creating your own build infrastructure does not increase your ability to be creative in your project. Sure, it increases your options, but that is not the point. There are already so many options, so many design considerations, our goal should not be to increase but narrow them. Constraint allows us to narrow our focus - in a good way - and ignore the gibberish to make good choices, else we even run the risk of being paralyzed by them and do nothing (analysis paralysis - or what psychologist Barry Schwartz calls The Paradox of Choice).

There is a neat little book out now called The Dip where the author (Seth Godin) goes into great depth about quitting. Quitting, it turns out, can be a godsend - and is something that most successful people have mastered. Why? Capital. We only have so much time/money/resources/brain-power to expend - and unless you use all available resources to a specific end, you will never be the best at anything - merely mediocre at a lot of things. This is hardly revolutionary stuff, but is another illustration of the point: constraining your actions through a narrow channel will allow you to reap the benefits of being the best at one thing. So what does this have to do with build systems? Expending your energy creating a custom build and release infrastructure is a waste of effort and - unless you are in the business of creating build systems - is almost certainly not what you should be doing with your time. Of course Maven has a learning curve - but that's all. You learn it - once - and the constraints allow you to focus on your task at hand. Maven is a style - and like iambic pentameter - rewards mastery, but is hardly constricting in a negative way.


Anonymous said...

Constraint allows us to narrow our focus? Law prevents us from ever getting into arguments on what's right, and what's wrong, but being so acute can mean everyone walks on their hands for the sake of constraint.

Eric Redmond said...

Reductio ad absurdum is not a relevant counter-argument for a general principal. You can always find a specific case where any principal breaks down. Hell - there are cases where the 2nd Law of Thermodynamics breaks down - big deal.

Clearly one can take it too far - but I was only commenting on the "constraint == bad" attitude that is all too prevalent amongst Maven's critics. Oddly enough, the same complaints I heard from structured programmers fighting against OO - you don't hear much from them anymore. And from structured programmers from assembly writers. This anecdote displays the latter (from Wikipedia):

P. J. Plauger, an early adopter of structured programming, described his reaction to the structured program theorem:

"Us converts waved this interesting bit of news under the noses of the unreconstructed assembly-language programmers who kept trotting forth twisty bits of logic and saying, 'I betcha can't structure this.' Neither the proof by Böhm and Jacopini nor our repeated successes at writing structured code brought them around one day sooner than they were ready to convince themselves."

Now replace "assembly-language" with "Ant", and "structured code" with "Maven" - and you have my general point.

But to your case specifically, this is why I illustrated self constraint - Picaso, et al - which is clearly alterable if it becomes absurd and unproductive. Law doesn't have to "come from above", nor make you feel powerless. If you have a compelling reason why we shouldn't walk on our hands - well - try and change it.