Cutting Through "Technological Mythology"

"Java is slow." "Windows always crashes." "We have to do it this way; it's the way we've always done it!"

As we grow at work, I find the rules of thumb that I usually follow and ask others to do the same have become carved in stone. Those who don't fully understand "why" they're doing it have taken it as immutable doctrine. When I ask for minor deviations in these rules of thumb, I'm met with resistance! My own words are fighting against me!

Years ago, when I also wore the "build master" hat, I would put a cut of our weekly release to server #13 for QA to smoke test. Thirteen is a lucky number for me. Eventually we hired some poor soul who now does our builds. They still smoke test on server #13 every week.

When I suggested the other week that they rotate which server smoke testing is done on (as we've got a fair number now), I was met with "but we *always* test on #13! We have to test on that server!" QA wasn't quite sure why though.

Technological mythology forms when people are dealing with a complexity they don't understand. It forms easily, spreads like wildfire through all kinds of mediums (email, wikis, conference calls) and is hard to combat. Education doesn't work. It can be more painful to untangle than your CIO's SOA plans..