Tuesday, February 28, 2012

Using Mongoid, MongoHQ, and Heroku

I recently tried to set up mongoid with a free mongohq account on heroku... This info is accurate as of 28 Feb, 2012.

For the impatient (I just want to make it work)

mongoid.yml

production:
  uri: <%= ENV['MONGOLAB_URI'] %>

Gemfile

gem 'bson', '1.3.1'
gem 'bson_ext', '1.3.1'
gem 'mongoid', '2.0.2'

For those who want more detail (I have a similar problem, how do I troubleshoot

To determine heroku environment variables, do this:

$ heroku config

and the results should contain a line like what follows:
...
MONGOLAB_URI        => mongodb://heroku_app928349384:lkfjgoierheourhgoeurhgoeuh@ds031087.mongolab.com:31087/heroku_appapp928349384
...

The important thing to note is what the left hand line says. Around the internet (like here on SO they will incorrectly name the ENV as MONGOHQ_URI. So then update mongoid.yml like this:

Additionally, it appears that different versions of mongoid only work with certain versions of mongodb. I started by digging around on google to find versions that seemed to be compatible.

Stack trace with wrong URI:
production:
  uri: <%= ENV['MONGOLAB_URI'] %>

Will yield something like

2012-02-28T12:49:46+00:00 app[web.1]: /app/.bundle/gems/ruby/1.9.1/gems/mongo-1.3.1/lib/mongo/connection.rb:518:in `connect': Failed to connect to a master node at localhost:27017 (Mongo::ConnectionFailure)
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongo-1.3.1/lib/mongo/connection.rb:656:in `setup'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongo-1.3.1/lib/mongo/connection.rb:101:in `initialize'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongo-1.3.1/lib/mongo/connection.rb:152:in `new'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongo-1.3.1/lib/mongo/connection.rb:152:in `from_uri'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongoid-2.0.2/lib/mongoid/config/database.rb:86:in `master'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongoid-2.0.2/lib/mongoid/config/database.rb:19:in `configure'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongoid-2.0.2/lib/mongoid/config.rb:114:in `from_hash'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongoid-2.0.2/lib/mongoid/config.rb:342:in `configure_databases'
2012-02-28T12:49:46+00:00 app[web.1]:  from (eval):2:in `from_hash'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/mongoid-2.0.2/lib/mongoid/railtie.rb:64:in `block in <class:Railtie>'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:25:in `instance_exec'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:25:in `run'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:50:in `block in run_initializers'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:49:in `run_initializers'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:49:in `each'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/application.rb:134:in `initialize!'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/application.rb:77:in `method_missing'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/config/environment.rb:5:in `<top (required)>'
2012-02-28T12:49:46+00:00 app[web.1]:  from <internal:lib/rubygems/custom_require>:29:in `require'
2012-02-28T12:49:46+00:00 app[web.1]:  from <internal:lib/rubygems/custom_require>:29:in `require'
2012-02-28T12:49:46+00:00 app[web.1]:  from config.ru:3:in `block (3 levels) in <main>'
2012-02-28T12:49:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:23:in `eval'
2012-02-28T12:49:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:23:in `block (3 levels) in <main>'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `instance_eval'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `initialize'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:63:in `new'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:63:in `map'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `initialize'
2012-02-28T12:49:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:18:in `block (2 levels) in <main>'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `instance_eval'
2012-02-28T12:49:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:11:in `block in <main>'
2012-02-28T12:49:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:11:in `new'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `instance_eval'
2012-02-28T12:49:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `initialize'
2012-02-28T12:49:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:1:in `new'
2012-02-28T12:49:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:1:in `<main>'
2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/rack/adapter/loader.rb:36:in `eval'
2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/rack/adapter/loader.rb:36:in `load'
2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/thin/controllers/controller.rb:175:in `load_rackup_config'
2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/thin/controllers/controller.rb:65:in `start'
2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/thin/runner.rb:177:in `run_command'
2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/thin/runner.

2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/bin/thin:6:in `<top (required)>'
2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/bin/thin:19:in `load'
2012-02-28T12:49:46+00:00 app[web.1]:  from /usr/ruby1.9.2/bin/thin:19:in `<main>'
2012-02-28T12:49:47+00:00 heroku[web.1]: Process exited with status 1
2012-02-28T12:49:47+00:00 heroku[web.1]: State changed from starting to crashed

Stack trace with wrong version of mongo/mongoid/bson :

Starting process with command `thin -p 4644 -e production -R /home/heroku_rack/heroku.ru start`
2012-02-27T22:50:46+00:00 app[web.1]: /app/app/models/expression.rb:2:in `<class:Expression>': uninitialized constant Expression::Mongoid (NameError)
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/app/models/expression.rb:1:in `<top (required)>'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/engine.rb:138:in `block (2 levels) in eager_load!'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/engine.rb:137:in `each'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/engine.rb:137:in `block in eager_load!'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/engine.rb:135:in `eager_load!'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/engine.rb:135:in `each'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/application.rb:108:in `eager_load!'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/application/finisher.rb:41:in `block in <module:Finisher>'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:25:in `instance_exec'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:25:in `run'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:50:in `block in run_initializers'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:49:in `each'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/initializable.rb:49:in `run_initializers'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/application.rb:134:in `initialize!'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.8/lib/rails/application.rb:77:in `method_missing'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/config/environment.rb:5:in `<top (required)>'
2012-02-27T22:50:46+00:00 app[web.1]:  from <internal:lib/rubygems/custom_require>:29:in `require'
2012-02-27T22:50:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:23:in `eval'
2012-02-27T22:50:46+00:00 app[web.1]:  from <internal:lib/rubygems/custom_require>:29:in `require'
2012-02-27T22:50:46+00:00 app[web.1]:  from config.ru:3:in `block (3 levels) in <main>'
2012-02-27T22:50:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:23:in `block (3 levels) in <main>'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `instance_eval'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `initialize'
2012-02-27T22:50:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:18:in `block (2 levels) in <main>'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `initialize'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:63:in `new'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:63:in `map'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `instance_eval'
2012-02-27T22:50:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:11:in `new'
2012-02-27T22:50:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:11:in `block in <main>'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `instance_eval'
2012-02-27T22:50:46+00:00 app[web.1]:  from /app/.bundle/gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/builder.rb:46:in `initialize'
2012-02-27T22:50:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:1:in `new'
2012-02-27T22:50:46+00:00 app[web.1]:  from /home/heroku_rack/heroku.ru:1:in `<main>'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/rack/adapter/loader.rb:36:in `eval'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/thin/controllers/controller.rb:175:in `load_rackup_config'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/rack/adapter/loader.rb:36:in `load'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/thin/controllers/controller.rb:65:in `start'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/thin/runner.rb:177:in `run_command'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/bin/thin:6:in `<top (required)>'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/thin-1.2.6/lib/thin/runner.rb:143:in `run!'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/bin/thin:19:in `load'
2012-02-27T22:50:46+00:00 app[web.1]:  from /usr/ruby1.9.2/bin/thin:19:in `<main>'
2012-02-27T22:50:47+00:00 heroku[web.1]: Process exited with status 1
2012-02-27T22:50:47+00:00 heroku[web.1]: State changed from starting to crashed
2012-02-27T22:50:48+00:00 heroku[router]: Error H10 (App crashed) -> POST newsfilter.heroku.com/_heroku/console dyno= queue= wait= service= status=503 bytes=

I apologize in advance for the poor formatting on this post...

Friday, February 24, 2012

Governance Gone Wild

I've written in the past about change control processes and how they relate to agility. Taking things to the next level, there's a bigger issue that needs to be addressed.

There are essentially two radically divided camps on what value IT Governance provides for enterprise software. These camps are: #1 the business camp which is tired of hearing excuses about why they are losing millions of dollars of business because IT cannot deliver a solution in a timely manner and #2 The IT camp that is tired of the business camp requesting crazy stuff and causing millions of dollars of unnecessary support costs. Camp #1 thinks governance is an excuse for IT/process wonks to slow things down or foot drag instead of delivering solutions. Camp #2 thinks governance is a way to reign in the business folks who believe that unicorns and pixie dust cause fully configured computers and network infrastructure to magically appear over night.

I hope its obvious that both camps are spectacularly wrong. While they both have arguably good reasons for what they're trying to do, I can attest to the fact that it's really (REALLY) hard to see that in the middle of a heated discussion between the two. Governance has often taken on a negative connotation to many because the ivory tower thinkers at many consulting companies treat it like a one size fits all religion where some ultimate authority is in sole possession of knowledge about what "the right thing to do" actually is. In reality, creating an agile, lean, and effective IT governance process is not about finding the right enlightened group with unique insight, but more about communicating vision and verifying that everybody is making decisions in line with that vision.

I feel one problem is that of the word "governance" itself. While wikipedia has a pretty good definition, to most folks, it implies active control. I contend the real goal is inculcating corporate goals to the culture and building transparency into the decision making process. Instead of doing this, though, organizations often relegate the decision making process to "czars", "councils", or "review boards" with the implication that they are somehow more knowledgable about what needs to happen. This is a sure fire way to slow things down, create an overly bureaucratic system, and ultimately get nothing done. It is better to let people do what they think is necessary to further the corporate goals, but develop a system to detect when things are going the wrong way as well as correct and avoid inappropriate activities.

A small example of such a problem would be in typical software change review process. Often, the "controlling" model ends up with a goal to restrict changes or make them difficult with the desired effect of limiting the amount of "bad" changes or "mistakes" someone might make. This can mean things like restricting access to the SCM tool and/or requiring multiple approvers to make a change, it also might mean only certain people can contribute to certain areas and all the administrative access problems this entails. To make matters worse, the approvers/reviewers in this model are often the more/most senior folks in the organization or people who actually don't have any working knowledge to understand what the change actually does. An example would be when a "change review board" consisting of managers/VPs is supposed to review java code changes. In my experience, there is typically no way they can have the time to actually comprehend what the change actually is. This has the effect of demotivating contributors because no matter how hard/fast they work, they can never be better/faster than the reviewer(s). It also implies that the reviewers somehow are smarter or have more knowledge about what is actually supposed to happen. The more obvious problem is that while the process limits "bad" changes, it also limits "good" changes.

A better way to handle this is to make the review process a little more democratic. While there might still need to be a senior person to resolve conflict, developers should be able to review/approve each other's solutions... this could even be done "after the fact", namely, developers can contribute code and move on, letting the review process "just happen" without their involvement (unless there is a question). It also puts responsibility for changes in the hands of people who SHOULD BE most informed about the goals of the change. Put another way, if the VP of Operations (or architecture) has a better understanding of business value of a change than the developer... the system is broken.

The ultimate problem with command and control style governance is that it often ends up turning into a "not my problem" situation. That is, the perception becomes that knowledge of "what is right" becomes reserved to a small group of people and they become gatekeepers whose objective ultimately becomes trying to restrict changes instead of facilitating proper change. People then lose sight of their personal contribution to the success of the organization and it becomes a downward spiral of ineffectiveness.

Wednesday, February 22, 2012

Architectural Antipattern: "Through The Looking Glass"

An anti-pattern is a commonly occurring pattern that is ineffective.

There is an architectural anti-pattern I like to call "Through the Looking Glass". This is when a system is broken into pieces or layers, but the pieces are cut perpendicular to the direction that the team and the business require. A common example is when a set of screens used to access a database system is split system into "front end" and "back end" components.

This "front end" and "back end" split ONLY makes sense if the back end can identify thier required interfaces before the front end is designed. If the "back end" requirements are being driven by the "front end" screens and/or systems, then this split is either #1 wrong or, at a minimum #2 premature. Most often, new systems need a front end to identify APIs that need to be used... it's more economical to build the system in such a manner that a front end change can quickly be migrated to the "back-end" (like rails) and enable using functioning software to be delivered early. The prudent thing is to then refactor and cut the system into pieces when necessary (or ideally just before necessary :).

I personally believe this problem is primarily caused by two things: over specialization and over engineering. Over specialization can be recognized when, for example, database administrators have no idea how the users will use or interact with the data. This can be combated by mixing DBAs into project teams as contributing members, not just people who sit around and wait for change requests to generate tables. Over engineering can be identified by looking for decorations inside the system design that are "for future growth" or other vague non-functional requirements. This can be solved by repeatedly asking the question "Are we actually gonna need this?"

Monday, February 20, 2012

The Best Practices Myth

I've found the term "best practices" to typically be a magical incantation that people invoke to use a fictitious third party expert to support their position. When most people say "best practices dictate" they're really just saying "because I said so" and I meet them with extreme skepticism.

This is not to say that the idea of "best practices" isn't alluring. Wouldn't it be great if we could simply do things the "best" way and not have to think about what we're doing. In fact, sometimes it might be valid, for example a "best practice" in java is to follow a naming convention. The first letter of classes should be upper case for example. I think this is reasonable, but frankly I'm currently hard pressed to understand WHY.

If you're going to recommend best practices, I feel you have an obligation to be able to explain the NEED of the "best practice" as well as the value. If the NEED is because someone needs to control someone else, be suspicious. If the need is that many people need to be able to attack a similar problem in a similar manner, then it might have some merit. That also means that the "best practices" are situational and need to be identified with the appropriate context. For example, following a java naming convention in python would not be extremely valuable.

Friday, February 10, 2012

people are not interchangeable cogs, they are more like the wind

Great organisations understand that people are not interchangeable cogs, but the wind in their sails.

I've struggled to come up with a metaphor that helps explain why command and control processes are so failure prone. In a command and control process, someone (or worse yet a committee) decides "how we're going to do things" and then builds a process to support this idea. Truly degenerate cases will take a step further and try to buy tools and then build their process around their tools. These struggling organisations then spend years try to find the right people or mold people to fit into their process.

These organisations have fallen into the trap of thinking that people are just pieces of a giant machine and that once they state their process, they simply need to find the correct pieces and hook them together. The problem with this perspective is that people are immensely variable. Finding two identical people is impossible (even identical twins are different in many ways) so the metaphor is fatally flawed. Worse yet, many of these processes try to LIMIT the amount of variability between people to make things "simpler", but in doing so limit the positive energy any individual can bring to the table.

A better metaphor is to think of the people in your organisation as the wind and it is the job of leaders to build processes that can harness and direct this power. This requires a big change of thought from the "interchangeable parts" perspective. Wind is intensely variable but carries tremendous energy... Sailors and shipbuilders recognise this and instead of trying to fix the wind so it always blows in their favor, they build, plan, and execute knowing that the direction and force of the wind is outside of their control.

Joe Wilner has an interesting blog post about why making the adjustment and treating people like the wind has positive impacts on the individual. The positive effects of this attitude change are much larger than any one individual. When you're looking around at your processes and wondering why "those stupid people" are not doing things correctly, perhaps it's time to re-evaluate things and look at the situation with a fresh perspective.