Fear of Change
Perhaps one of the most dangerous fears of Man is the fear of change. It is a fear of the new and a desire to remain close to “the old ways”. This occurs on a macro and micro level. On a macro level, it turns once progressive nations inwards and backwards. Such is the case with many of the Islamic states around the world where extremist groups denounce the ways of the West and force the government to enact stricter codes adhering to the old ways and to Islam.
It happens on a micro level, too. My wife refuses to try sushi (not that I like it much myself, but I’ve at least tried it) not because of any real reasons like allergies or whatever, but because of fear. It is a fear of the different, a fear of the new, and a fear of the unknown. You can look at it, smell it, and poke it…but you won’t know whether it tastes good until you put it in your mouth.
Perhaps this is a natural and reasonable fear that has developed through years of evolution and natural selection. Certainly, that red berry looks edible, but no one has ever eaten one…so who should be the one to test whether it is edible?
As a developer, though, this fear bothers me a lot when I see it in others. While I do not claim to be free from it, I’ve always adopted a stance of at least giving every technology a chance before making judgements. I keep a directory called “Sandbox” on my disk drive where I dump all of my code that I use to play around with various technologies, tools, and frameworks. I believe the only way to learn whether such things are useful is by actually using them, practicing their principles, and understanding how they work.
In a sense, the landscape of the software development world is like a giant buffet; there is so much variety, so many flavors, so many dishes, and so many variations of dishes, that it can be comforting to just stick with what you know and be a little skeptical about dishes that look foreign and/or different from your staple diet. It’s quite a shame to go to a buffet and only stick to two or three dishes isn’t it?
Perhaps it’s because I’m younger, but I don’t think much about trying out this framework or that tool package. I only know that I can’t discern whether it suits my “taste” until I try it at least. Too often, working with the older generation is like taking my sister in law out to eat with us; her diet basically consists of chicken fingers, burgers, and occasionally, steak. It’s frustrating to no end because she refuses to give anything a chance that even appears to be mildly “icky” like fish or mushrooms.
From a development perspective, such fears ultimately lead developers to cling to hold habits and old ideas because they work. It burdens a developer in the same way that a fear of a “mechanized cart” would burden a man who refuses to trade his mule pulled cart for a car. More importantly, it means that the ability to improve efficiency becomes limited by the ability of the developer. This saddens me because these tools, frameworks, and practices are all developed with a singular goal: to make development easier. Developers who hold this fear of the new and this fear of change close to their hearts ultimately sacrifice productivity for comfort. While not all packages, tools, and practices lead to results (much like not all diets will lead to weight loss), it is very difficult to tell (unless the ideas are absolutely absurd) whether the idea is useful unless it is tested in use.
But I think one has to go even further than that. Evaluation cannot be done half-heartedly; one has to adopt the mindset of those using the tools and frameworks. One must adopt the philosophy of the tool or framework in question. Simply using the tool or framework without dropping one’s typical practices and mindset for new ones (at least temporarily) will not do much good at all as it only leads to the inevitable “discovery” that “this tool doesn’t do what I want it to do” or “it’s no better than what I was using anyways”. Is that really the case? Or is it really that it means that an old way of thinking requires some adjusting?
A good example is NHibernate, which allows users to still use ADO.Net like data retrieval patterns via direct SQL queries (since there are obviously cases where it may be necessary, especially when bootstrapping it on top of an old/poorly designed database). Some would try it and proceed to only use the direct SQL queries. Evaluating NHibernate, then, without dropping the ADO.Net mentality leads the evaluator to a “it’s no better than what I’ve been using” conclusion.
So what’s the moral of this post? Don’t be afraid of new frameworks or new tools. I absolutely hate it when developers generalize and flat out state “well, from my exprience, frameworks are always more of a hassle than they’re worth“, “they never do exactly what I want it to do“, or “it’ll take too much time to learn the framework” without having written one line of code against the tool, framework, or library. First of all, it’s a fact, 99% of all generalizations are false :-). Secondly, these types of statements cannot be made accurately until actual code has been written.
Hunt and Thomas write, in chapter 1 of “The Pragmatic Programmer”:
Managing a knowledge portfolio is very similar to managing a financial portfolio:
- Serious investors invest regularly–as a habit.
- Diversification is the key to long-term success.
- Smart investors balance their portfolios between conservative and high-risk, high-reward investments.
- Investors try to buy low and sell high for maximum return.
- Portfolios should be reviewed and rebalanced periodically.
Just like financial investments, it pays to diversify, to try new strategies, and it always pays to put in a lot of heavy lifting into researching a particular investment. Tools, frameworks, and libraries already in one’s portfolio should always be subject to re-evaluation and perhaps, when the time comes, it may mean that one’s knowledge portfolio needs to be rebalanced.
