I’m often asked why I don’t hop on the lastest language bandwagon and just start coding up a storm. The answer comes in two parts: the first is that I do try out these languages to see what the hype is all about, to see where they can fit in and to see their pros and cons. The second is that I realize that there is more to software engineering than just writing code. Software spends disproportionately more time in maintenance than it does in initial development. Just because a language such as Ruby is much faster for initial development doesn’t mean that it’s much easier to maintain. (Do note that I’m not saying that Ruby is hard / harder to maintain. I’m simply saying that a one cannot determine what the maintenance model for a language is from doing only initial development.) The long and short of all of this is that I am forced by my professionalism and my responsibilites to not only look at how a language works for initial development but also for long term maintenance. By definition this means that it takes me a very long time to determine if a language is suitable in the long term. Since many newly in vogue languages simply haven’t been out long enough to have either the community’s or my own understanding of its maintenance model one simply cannot start writing production code with them.
One quick example of all of this is AOP. I’m enamored with AOP but I cannot and will not use it in production software. The reason is that AOP simply does not have a maintenance model at all. In other words, I cannot take an AOP’ified application and future apply AOP on it (i.e. maintain it) and have understandable and determinable effects.
Editor’s note: this is a stream of consciousness posting to get an idea down and is not complete or thorough in any way. But as always, comments are welcome.