Preserving survival rules in face of enthusiasm
Paul from infrared must has surely had a terrible experience in the past jumping on some flavor of the month, but then being horribly burned when that flavor lost taste and he was stuck without the flexibility to solve the problems at hand.
Buy who hasn't? Most of us have experienced jumping on the wrong bandwagon only to be end up in a dead-end situation and the feeling of being abandoned. Experiences like that leaves scars.
We deal with those scars by building survival rules like "don't trust something until it's been around for years (or you will be burned again)". In some regards these survival rules help us navigate the world at a greater pace because they can serve as filters for what should be deserving.
Survival rules are rarely something we think of consciously — unless provoked. And it certainly seems like Paul was provoked:
If I switched to using the Next Big Thing, only to find that the thing we need to do to keep Client X happy is actually impossible or fraught with bugs, we're fucked. You need total flexibility, because no matter how smart they think they are, the designers of any web application framework can never have thought of everything.
In other words, he's tempted to play with new technology, but the survival rule is telling him not to — don't mess with something that works, the promises are false (like the last time). The source of this provocation is outlined in the introduction:
A lot of people (especially people who submit stories to Slashdot) are going doolally about Ruby on Rails, the Next Big Thing in web application development. You can't read a blog without someone going on about it like it's the second coming. The end of PHP/J2EE/mod_perl/python/blah! Everything before it is shit! It makes everything so easy! Why on earth are you using anything else, ever, at all? You web development savages!
Leaving aside the internal amplification of the original messages that Paul applies in his understanding (that's an interesting topic for another time), I believe what he's hearing is the voice of a lot of people violating his survival rule around adopting new technology.
That's a challenge, which can be dealt with either by reexamining the survival rule (and asking whether it's helpful to apply it in this case or not) or by distancing himself from the source of the challenge, so as to render it invalid (it doesn't apply to me).
Paul picked the latter and uses a "there are two kind of people" dichotomy to describe why the challenge doesn't apply to him (and thus why the survival rule can still work). The split is centered around "...hype about whatever the Latest Cool Thing is for building pointless web sites and the needs of people like myself, who build web applications professionally".
We have the Bad Technologists (using Latest Cool for pointless web sites):
I wonder how many people are getting hold of RoR, understanding it a bit, using it to write a piss-poor CMS for their weblog or a widget engine, and then never using it again.
These people obviously don't care about the important issues that the Good Technologists follow:
I wonder how many people like me, who rely on the tools they use to be mature, stable and (above all) familiar, in order to Get Stuff Done, when there's never enough hours in the day and the site's going live tomorrow or they pull the contract.
With the world divided into good and bad, it's not hard to pick the side of the good. And thus, it's safe to render the conservative, survival rule-preserving conclusion:
Meanwhile, I stick to mod_perl and Stuff That Works because the track record gives me faith in its persistence. I'm not playing at this, it's my livelihood, so jumping horses onto an unknown runner isn't a risk I feel I should take.
What do I make of this? First of all, that it's not really or at all about Rails. This is a fundamental defense mechanism that any new technology, development approach, and way of thinking will encounter. So in that sense, I consider it a sign of good things when we force survival rules to be invoked (and subsequently examined). That's definitely the first step.
The second step is of course to figure out how to help people make more informed decisions, so they have better grounds on which to decide whether the survival rule is helping or hurting them.
I surely didn't pick the right approach in one instance that Paul highlights, but at least I realized and attempted to revert that approach the day after (Paul doesn't link to that).
So. I won't try to convince Paul with my own words just now. Instead, I'll let Mike Clark attempt to address the issue of flexibility in the Rails world. He has a wonderful piece called Dumpster-Diving Rails, here's a snippet:
I'd also encourage you to study the Rails code just for fun. There's a lot of incredibly cool stuff going on in there, and just reading the code will make you a better Ruby programmer. You shouldn't be afraid to take a peek; it's good code. Being able to read, tweak, and run the Rails code with ease drastically lowers the price of participation.
In much the same way that the web took off because of "View Source", Rails is taking off because it lowers the barrier to entry and holds nothing back.
(If you want to read more about survival rules, I can recommend the writings of Jerry Weinberg — the Quality Software Management series and the Secrets of Consulting series deals with them at length)
