A plan against planning

I was most recently part of an organized gaming match among thirty-two players. Two days before, a meeting was called to carefully lay out which directions groups would go, and how everything would be built, stacked, and executed. Almost down to dotting the little ‘i’.

As you, the reader would know, this plan went completely out the window as soon as virtual feet hit the virtual pavement. My team ‘won’, but the only plan that followed was common sense among people who knew what to do.

Weddings and other big events work in similar ways with similar dynamics. Plans only serve to answer questions of how things should be done if one does not know how.

These are things that happen in the course of execution like where the groom and bride should stand, or where the place settings on the table should go.

It is only by natural circumstance that the groom doesn’t completely run in circles while walking down the isle (although I presume that some have).

Plans are in essence part-way of being a hindrance. Nothing ever really goes to plan, and some things should never be planned (unless they are so obscure of an idea that they should be — such as building blueprints for instance).

The best that one can do with a plan of any sort is to control chaos. Almost always however, it is better to just allow people to train people to react, in a boolean logic sort of way.

A nice example of this is in a concert. A concert is a collection of people working all at once to play out a common piece of music. It is a very refined form of chaos. Players are given sheet music, and told what to play, how to play it, and when to play it by a conductor.

A concert is a great form of how planning should work; the players are (usually) not told how their breathing should work, and what the best position for their fingers are. Quite simply, they know all the little things, and how to adjust their actions to fit in with the big picture.

This type of training falls out of the scope of any general plan, but these people are simply better known as folks that can ‘do it on the spot’, either because they have prior training, or instinctively know how something should be done properly.

People who can adapt and adjust quickly to align themselves with the plan (“play some sheet music”, “defeat the other team”) are the ones that make any plan successful. Those who try to plan excessively instead of allowing people to adapt on the spot risk diluting the original plan (the more important message).

The more important thing is that it risks alienating the people in the plan, who may feel that they know how to, for instance, hold a football while catching a pass. The prime message of the plan is lost.

Thus a complicated plan is never a solution to a complicated problem. Practice helps greatly, but is no substitute for having people around with great sense of what they already need to do, and how to react when the time is right.

If you can’t find people that can adapt, it is probably better to just train them, or toss them, but it should never be okay to treat them as programmable robots. It is both a waste of your time, and theirs.

Advertisements

Pushing forward

With the Arduino movement fully underway and unlikely to lose steam, there is something to be said about how the world was before it.

Revolutionary ideas take things that were once hard and distill them into safe, guided, and easy experiences.

Some of the more experienced scoff at projects like Arduino because at the core, they eat into hard knowledge bought with time. A computer scientist might be a bit miffed if tomorrow they would be somewhat replaced by clever self-optimizing algorithms (pending the submission of a million dollar proof, of course).

Before Arduino, building an AVR breakout board from a knowledge base of zero would have required knowing even beginning electronics lingo (by asking such inane questions like: “what is ground?”) to finally making the selection of AVR over PIC, ARM, FPGAs and otherwise.

A beginner doesn’t really need to understand the innate difference between a crystal and a resonator (the crystal has better quality), or why one is needed in the first place (its used as a sort of heartbeat for microchips).

This is often why hard problems remain hard, and why few people tackle them. Smart (and rich) people remove irrelevancies like these.

Good projects that change the world have this embedded in them as a core value (distilling hard problems) and have become wildly successful because they pander to the masses, and not exclusively to the experts.

Ubuntu for instance, became synonymous with “Linux” on several forums because it was a great entry-level distribution.

Ruby on Rails for quite some time has been the de-facto web framework, and arguably ushered in MVC as a mainstream way of doing web development. Its framework and “opinionated” way of doing things made web development less boilerplate and more manageable.

Knocking down barriers is something that can be done with nearly all that is hard in every field: Mathematics, Biology, Teaching, and Engineering.

While brain ‘trusts’ are nice and elite, drawing many smart people to a field and having them stay is more valuable to society as a whole.

Here is to the next framework, or hard problem solver that makes a massive splashdown on a problem once ruled solely by experts. Things can only get more interesting as people figure out how to craftily exploit making hard things easy. Because problems only get more interesting.

Gender in technical documentation (and writing everywhere else perhaps)

Have you ever passed over a piece of text that said “this will really piss off your Administrator. She is likely to…” or “of course, you can give your DBA a cookie. He’ll appreciate it.”

People who are sensitive to how gender is used will generally pause in short stops there, wait a bit, reflect, and continue. Before somebody brought this up I never really realized it. I find myself doing it sometimes. Personally, I find that this is more of a nitpick than anything else (and to book authors it is).

Why is gender an issue?

Perhaps we have been moved toward gender equality so much that we are becoming hypersensitive toward single-gender selection in literature, and instead of being exclusive, we are becoming inclusive (using “s/he”, for example).

In most cases, people skate the issue by modifying their examples to use names, instead of genders (Joe, Jane, Jay, Matt, Ryan, Alice, Bob, etc).

Maybe we’re all just too sensitive. And maybe we shouldn’t open up this can of bees. (Penn and Teller)

Shifting the paradigm

To make a long story short, I recently logged out of Gmail, and discovered a link to this YouTube video. It was kind of cheesy, and a little corny, but it was watchable (it didn’t kill me).

The comments were full of bashing, swearing, and cursing by Gmail users who felt it their duty to voice how they felt ignored, and how Gmail’s sorting of information was the worst ever invented.

Interestingly enough, a paradigm shift is when a widely held belief (such as the theory in which the mind and body are separate a la Descarte) changes. It is often joked (and said) that for a paradigm shift to occur, those holding the current paradigm need to die off.

E-mail, like nearly everything else on the Internet was once very open and trusting. These systems were primarily designed in academia (the Linux kernel was designed by Linus Torvalds while he was a student), where “trust” was open, and as such security wasn’t that big of an issue back then. Information was cool, and sharing was even cooler. MTAs (the server(s) that you communicate to when you want to send e-mails) were often setup by default to relay e-mail (a large source of spam some years ago, now not as big of a problem as evidenced by the shutdown of ORDB) and nobody was none the wiser. We got used to it then, all this sharing and openness. It was cool.

E-mail evolved into what it is today, with .maildir folders, and Mbox files for storage. Without getting into specifics, the e-mail folder on many IMAP servers is nothing more than a directory structure which holds your e-mails. Have you ever seen a directory tree with the little pluses and minuses a la Explorer in Windows? Its just like that. Your e-mail is generally stored like that.

We’ve been using folders for a long time now, and the idea of the folder has become deeply ingrained in our sense of organization. Its natural. When an e-mail from Aunt Mag comes in, we put it in the Aunt Mag folder. When a reply to that NSA** off of Craigslist comes in, well..you delete it, and it goes away after you’re done with it.

Google called (and still is calling) for a paradigm shift, by simply changing the way we think about e-mail. It has not been without controversy.

Many technically aware people will probably recall when Gmail proposed using the content of e-mails to deliver advertising. Politicians and privacy advocates were beating their drums so loudly that they drowned out technical speakers with actual reason, than emotion.

At Google, there was a small paradigm-esque shift in the way they thought about advertising and e-mail too, although a very short one. Google’s senior management had first believed the very thing that many others had believed (parsing e-mails for advertising content was privacy intrusive). Initially, the idea was scrapped. The story* goes that a coder wrote in the system for contextual advertising anyway and linked them up with the e-mails. It was then re-presented to Google’s Larry and Sergey. They didn’t think it was so scary after seeing it again.

However, they probably realized what the world was thinking. The world was about to do the same thing when Gmail was released (into beta), except on a grander scale.

When Google got attention for their form of targeted advertising, people were in uproar. Senators got involved, and in general people donned their tin foil hats, clutching their copies of Orwell’s 1984. For many people, it seemed as if major corporations were coming down to take over the world.

To make a long story short, such parsing wasn’t new in the computer industry at all, it was automated, and to many computer scientists, trivial. Other agencies were doing the same form of contextual parsing in one form or another, and Google itself already had the e-mails. If they wanted to do something nefarious with them they could. Your own ISP could be doing the same thing, and so could Yahoo, or Hotmail. If you didn’t trust Google, how could you trust anybody else? Sure, you could run your own mail server but that entailed managing it. Software updates, spam maintenance, security tightening, backup issues, mail queues, load management..

E-mail (disregarding things like PGP signing/encryption) is an insecure medium, and one should not expect privacy when firing off e-mails through systems that are not within their direct control.

Going back to the YouTube video, labels, and such, are an interesting facet of how Gmail works. Instead of piling things into folders, you have labels. Aunt Mag no longer has a folder. She is in the same area as the NSA guy/girl down the street you go to every other week to have fun with**.

How is this different from a folder? A label’s feature is synonymous to a folder. When you click on a label it shows you all things that are labeled “xyz.” When you click on a folder, it shows you everything inside “xyz.”The archive is synonymous to clicking “show all e-mails” in your MUA (Mail User Agent, eg: Mozilla Firefox, Microsoft Outlook, etc).

Same same, no?

And if you’re wondering..I run my own mail system. But sometimes I get ticked off by it enough (managing a mail server can become a full-time job) that I just run stuff to my Gmail account.

* AFAIK, I do not have the original article/video and cannot find it. Please leave a comment with corrective material, and/or a link if you do know where to find it.
** No strings attached (I looked it up while browsing the best-of-craigslist).. your first interpretation of this is probably dead on.