I’m development manager in a small software house producing products written primarily in Java and a bunch of Java related web technologies and frameworks (the odd bit of C++ when we need something lower level).
When one of the developers comes to me and says “I want to knock up an internal tool in Perl / Python / Ruby / Visual Basic / Fortran / 6800 Assembler (basically anything that’s not on our core technology list)”, my immediate response is that I don’t want something we may not be able to support when that person leaves – internal tools have a way of becoming critical and you need to be able to maintain them independent of a particular individual.
My view is that it’s not as if I’m asking them to write a web app in C, our core technology list contains generally tools which are fine for the sort of job in question (if perhaps not as good as some alternatives), but how strictly should standards be applied in these situations?
(Marker as community wiki as I know it’s subjective – though not, I hope argumentative – but I’m sure people will close if they think it’s unreasonable).
Standards are, by definition, arbitrary restrictions on potential solutions. By nature, they don’t always include the ‘best’ tool for a given job (certainly not for all interpretations of ‘best’). But adhering to standards allows you to keep costs reasonable, and to stay flexible (avoiding situations where you don’t dare touch your toolchain because of a nonstandard technology for which you have insufficiently skilled staff). So generally speaking, be firm on your standards: you have an excellent case.
However, given the flux of the world in general and IT in particular, standards also need to evolve. That’s where you should leave some wiggle room for experimentation: allow your developers to throw together e.g. a Ruby tool to get a feel for it, but budget for its replacement with an approved technology, and don’t permit the original developer to maintain it, in order to get second opinions and decrease the risk of lock-in to the original developer. (Which, granted, is going to hurt in an emergency.) If the new technology works out and significantly surpasses your existing standards (key point!), consider phasing it in. But not without phasing out something else (in at least nine cases out of ten): you don’t want your standard portfolio growing uncontrollably.