Monday, July 30, 2007

Code Te Ching - Verse 23

Overworked and sleep deprived,
a good way to drive yourself mad.
a bad way to drive good code.

If a wandering goat herder can not work well without sleep,
how much less the coder?

Devices are no substitute for sleep.
The wise manager knows this and does not let his coders stray.

Sunday, July 29, 2007

Code Te Ching - Verse 22

When a heavy storm comes from the west, it attacks with torrential force.
When a small stream flows from the mountain, it glides with effortless action.

The heavy storm is fierce, but it soon blows itself out.
The small stream is soft, and it flows for ages to come.

The reckless coder is fierce at first, but cannot sustain his efforts.
If the earth cannot maintain such force, how much less the man?

The storm howls and makes a fuss.
The stream quietly carves a canyon.

The wise coder is like the stream.
Tenacity trumps force.

Saturday, July 28, 2007

Maven: Hyperbole

Code Te Ching - Verse 21

Consciousness is just a label:
    Advanced sentience.
Sentience is just a label:
    Advanced processing.
Processing what?

State precedes the next instruction.

To master control of state is;
To master control of mind.

Do not be prideful of your state.
Do not be prideful of your processing.

To know how to instruct,
One must first accept instructions.

Code Te Ching - Verse 20

Perfection is not the absence of errors.
Perfection is the perfect handling of errors.

Always checking values,
Always checking errors,
How pointless!

The wise know their own code.
The wise know the true value of "always" -
    And it is little.

Instead, the master:
Knows what to expect: honors contracts; or
Knows not what to expect: checks for errors.
But always the right prescription for the write code.

Tuesday, July 24, 2007

Code Te Ching - Verse 19

The computer is deep;
The mind is deeper.

Code is the bridge between the will and the machine.

Like ancient wizards whisper incantations to the wind:
    Reality opens up and abides.

So coders whisper instructions to the machine:
    Virtual reality opens up and abides.

But do not feel inferior to the mage.

The wise know this:
    Virtual is a facet of reality.
Thus the coder's command of reality is very real.

Monday, July 23, 2007

Unhealthy Activity?

Brett Porter posted the top contributors on the Maven user's list - naming the first 3 only.

By my own count I answered 61 threads - so that would put me at #14 or #15. I would have guessed far lower but numbers don't lie - I still feel like a slacker. I also feel like Wayne needs to get a life (j/k :) ) but I digress. 1485 people have posted so far this year - that doesn't make me feel very good. Sure, it's nice that people are interested in Maven, but looking at most of the questions it shows 2 things: Documentation still kind of sucks, and Maven is still too cumbersome and confusing.

I just started back into Rails after about 3 years, so not surprising I forgot it all. So I dove back into it - guess what? I don't need a Rails user group... it is well documented, snippets abound in the google fields, and most of all - it just plain makes sense. Half the time I guess the name of a method (I knew that "has_one :order" existed, so then I tried "has_many :orders" [note the plural] - it worked!). I've said it before and it still believe it: Maven needs a better face. The "wait 'till we get tooling" answer is losing water - it's been 2 years now. I believe in the project - I really do - but my faith is running out. Could it be the Buildr guys were right afterall?

Sunday, July 22, 2007

LOL Leel4r

Well, I'm hardly an LOL Catz "expert", but damn this picture of my baby Lela was just too cute.

Code Te Ching - Verse 18

Banish micro management, Discard process.

The smart men will come out of their shells
The lame will have no more theater from which to perform.

The smoothest winds will not allow a chicken to fly south for the winter
The clearest skies will not let a horse count the stars
The cleverest technologies will not let a bad developer write good code.
Expensive tools only let bad coders develop bad code faster.

Code Te Ching - Verse 17

When repetition arises, apathy abounds.
Therefore, the elite:
    does not loop what can be done once
    does not ignore encapsulation
    does not skip writing code to generate more

Saturday, July 21, 2007

Code Te Ching - Verse 16

A man without arms can still run,
code without comments can still run.

But both would be better off with the extra.

What good is code that no one can read tomorrow?

Man prints his view on the world to make sense of it,
Are his labors not a part of it?

Friday, July 20, 2007

Code Te Ching - Verse 15

The ancients who followed Code
Were energized, logical, efficient, subtle.

Tenacious beyond knowing.

Because they cannot be known
They can be described as:

    Mistakes cost great fortune.
    With many possibilities to choose.
    His acquaintances were few.
    His actions did the talking.
    He cared nothing for fame.
    Like an unsecured network.
    As in beer.

Calm the focus,
    Knowledge becomes clear.
Move the gate,
    It comes to life.

Because he knows Code
    He can develop undisturbed without wearing out.

Code Te Ching - Verse 14

Good code is like poetry.
A pleasure to read, and more to think about.

Better code is like music.
A pleasure to hear, and more to dream about.

Superior Code is like water.
Difficult to imagine life without it.

Code Te Ching - Verse 13

Comments are not for you:
Comments are for not-you.

When comments are commented for you now
meaning will be lost,
    even for you-future - not-you - to discover and not understand.
    comment for not-you - you-future - to discover and understand.

Code Te Ching - Verse 12

Finding your own bugs and fixing them: integrity
Finding your partner's bugs and fixing them: integrity
Why are they the same?

Of course there is no difference between self and other!

The parts do not define the emergent system.
All Code is one; hence, all coders are one.

Code Te Ching - Verse 11

A wise man once said:
Every good work of software starts by scratching a developer's personal itch.
That is to say: necessity is the mother of invention.

Leather is sewn to make a shoe.
    The shoe’s use comes from the foot-shaped hole.
Clay is formed to make a mug.
    The mug’s use comes from emptiness.
Electron is used to make a one.
    The one’s use comes from zero.

The zero is contained by one;
The one is defined by zero.

Lao Tzu thus said:
    Having leads to profit.
    Not having leads to use.

Code Te Ching - Verse 10

To know not is not to not know but to know.

Questions asked are not for the ignorant.
The knowing know the Code, but not all that it entails.

Only the fool professes to know it all
The elite knows only he knows nothing at all.

The coder is what he does, not what he says.
The elite always admits his own bugs.

Code Te Ching - Verse 9

Tools come in many sizes,
like people.

Some are small and fast;
Some are large and slow;
Some are old and still:
Some are brand new.
Of course this is meaningless.

Large is not better:
The truly great can code on a napkin.

Wednesday, July 18, 2007

Miscommunication causes Discombobulation

I've been there - and feel for you. As a former build-engineer charged with managing a crazy infrastructure I can attest to the fact this this is exactly how it feels. Atlas of the Builds, the weight of the system rests on your shoulders. Forget air-traffic controllers, forget Wallstreet stock-traders - managing builds can be one of the most stressful jobs - ever. Deploy fails at 2am, who do you call? Someone checks in bad code, whose email gets flooded? Some architect decides not to follow the build system standard, who gets blamed for the build breaking?

Yet, despite it all, code still builds and products get shipped. Upper management sees no problem - must be because of their great build infrastructure... yeah right!

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.