That's the whole idea, if your current "coding" habits are not efficient well changing them involves taking a risk... otherwise everyone would do it.
Humans have a tendency to stay within their comfort zone. Stretching that bubble takes time. No change however = stagnation and eventually obsolescence. I have never believed in the single hammer approach to all problems in a single project. However most customer projects I dealt with had this disease, the main reason being that was the "comfort" zone issue showing up in most of the technical decisions taken in the project. The day managers will stop looking at their developer's skills as something fixed and "immutable", projects will deliver with better quality and faster because there will be a choice of tools available for different parts of the same project and more flexibility resource wise. When my shop was working solely on custom components for our customers, I used to change people from one project to other according to the workload state at a couple of hours notice. New project, new technology... It's like moving a plant from one spot to a different one. It might be hard at first but at some point the plant gets stronger. This approach beats the hell out of people at first but as they are moved from one project to the other they see the light. They understand how to adapt and shift because of the constraints (time line, learning curve, ....) One big advantage of my employees versus plants: they were able to speak when they did needed some guidance. I must say that what I did was not a benefit for most that left for other companies since we stopped the custom software business. They found most of the time that their liberty was severely restricted in their new job compared to what they could do in my shop... Today, we can choose the appropriate technology for the task to do since we are now working on our own products. Our approach has not changed except that we have greater latitude in what we decide to use (and of course greater potential to hang ourselves). Luc On Tue, 2009-03-10 at 09:53 +0100, Christian Vest Hansen wrote: > Also, how do you think this increase in required effort grows? What if > we are talking about a +10.000-line Clojure program? Now add schedule > pressure, deadlines and the cost of missed oppotunities and you will > find that many companies sees the introduction of a new programming > language - especially if it is uncontrolled or happens without their > knowledge - as a significant risk. -- Luc Préfontaine Off.:(514) 993-0320 Fax.:(514) 993-0325 Armageddon was yesterday, today we have a real problem... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
