+972 52-548-6969
The difference between derivation and innovation
Occasionally people ask me what I think of tech X or tech Y. Usually it is something new that just came out and made a lot of noise in the blogshpere. My response is usually something along the line that: "I seen the promo, but it has the same plot as all others, so I skipped it."
It tends to surprise people.
Let me try to explain this with a bit more depth. The first problem that we have to deal with is that there is only so much that one can learn. As such, I have made a decision a while ago that I'll dedicate time to learn about new innovations, but will skip derivations until I actually need to use them.
There are a lot of new projects that are just another version of something that is out there, and in that case, they are not really interesting to me. If it is something new, it is interesting. If it is another variation, it isn't. If & when I need it, I'll learn the API and that would be about it. I am already familiar with the concept, so there shouldn't be an issue there.
I would have given an example here, but I have a long experience in examples back firing on me. Therefor, let us say that somebody come up with a new distributed queuing infrastructure. And they have Ajax support and it is the best new thing.
For myself, there are several issues with dedicating too much time to something like that. I already understand queues, and how to utilize them in my applications. There isn't anything conceptually new here. Therefor, I'll read the blurb, maybe read a post or two about the highlights, if they aren't copy & paste from the release announcement, and that would be it, until and when I need to use this.
Now, on the other hand, enough derivation is innovation. And small things can make a lot of difference. As a simple example, Binsor isn't really interesting in itself, it is yet another way to configure the container. The power that Binsor has gave way to a whole new way of thinking about configuring the container.
So yes, there is a chance to miss something important, but on the whole, I find that it is only after I actually used something for production, I can tell you what the real value is.
Comments
Ayende,
Hows the work on the book is going?
And the association to the topic at hand?
"I seen the promo, but it has the same plot as all others, so I skipped it."
That remind me the promo for ASP.NET 2: it was advertised as "write 70% less code" (hear 70% more tagsoup) and it was all about bland demo that has nothing to do with real world issue and was pushing the drag&dropers away from clean and nice design for the problem at hand (handling HTTP request and response in a maintainable way).
I've never had to learn the new API upfront, concentrating over the features of the new backend languages and more interesting framework parts immediatly usefull
That could stand true for many thing, I'm not jumping on or promoting a new thing unless there is a great probability it turns usefull for my projects and I've proved myself about this.
Your counter example about Binsor (derivation leading to innovation) is more dual derivation to the wrap and extend features of container setup:
fluent interface and/or DSL
scripting enabled language
it often takes more than one derivation to create something usefull and innovating, but there is nothing that mandate that such derivation must apply to the latest promoted framework, there is gap to fill all over our current base.
What miss is out of the box thinking more than being accustomed with the latest to extend it first (there, you may come up with reimplementation of what is lacking from competing solution).
The reason that I am saying Binsor led to innovation was that the power of scirpting language to configure the container has led me to creating rules to configure the containers, and that has affected the way I see working with the container.
This post strikes a chord with me. I sometimes find myself explaining to people that tech X, tech Y and tech Z all solve the same type of problem, so choosing between them is often down to the minutia (taste, particular requirements etc)".
But, if someone has no experience with that type of technology, then they can't see the conceptual similarities between the derivatives. So they're stumped. For all they know, each technology gives something completely new and different, and picking one seems impossible.
Innovation vs derivative is a nice way of putting it. It's more important to recognise that you actually need the the "innovation", rather than the particular derivative.
Comment preview