 |
|||||||||
|
|||||||||
|
|
In my personal experience, I notice that most developers would rather user a technique that takes longer (but for which they have complete control over), then a faster techniques (for which they can't really control). They want a slow and controlled shot over a faster, but random, one. For example, they'd rather use
A cumbersome open-source project (which lets them step through and modify all the code), than a powerful framework that they cannot modify.
An older technology that they've mastered, than a new one that "sounds" promising.
Their own code (that they know inside out), than someone else's, or a third-party, that's obscure.
To some degree, this makes sense. Who cares if a technology or component is powerful if you cannot harness that power? The problem is if you cannot control the code, it becomes not just useless, but rather dangerous. The un-intended consequences will kill your schedule. However, good developers need to constantly learn, and tame those powerful, yet still-wild, technologies. For example, a developer may be afraid of regular expressions, and comfortable writing tons of string-parsing code, but ultimately they need to learn regular expressions.
