Choosing the Right Development Tools for Your Organization
At one of my clients, there’s a debate going on about whether to control which development tools people use or not. In my mind, that’s a no-brainer; absolutely!
I say "Never let the inmates run the asylum." What I mean by this is that if you ask N developers what tools you should use, you’ll probably get N^2 answers. Developers usually shouldn’t make these decisions on their own. (I say this as a developer. I’d love to use Pascal or FORTRAN or assembler or FOCUS again, but would it make any sense???)
When I was 23 or 26 I always wanted to play with the cool new stuff, just like the 23 or 26 year olds today. What I didn’t have then was perspective on what works well over a long period of time. Now that I do, I know that the Wild West approach may seem like a good idea to some, but it’ll cause tears sooner rather than later.
Almost every organization I’ve worked with has an architect role or office that screens new tools and makes suggestions or edicts. How tightly the organization is tied to those suggestions or edicts depends on what type of organization it is. If a bank said "Let’s use whatever we want in our ATMs.", that would be a real problem. On the other hand, in an R&D environment, considerable leeway may actually make sense.
The academic model says "Let’s try anything and see what works."; the corporate model is usually more like "Let’s look at our overall strategy [the business strategy, not the IT strategy, at least first] and determine which tools will be the most productive and cost effective."
Cost effectiveness takes many forms: can we produce high-value solutions quickly and reliably, can we scale up our staff rapidly if we need to, can we keep up with new software versions reliably, can we build good institutional memory for maintainability, can we support our solutions, can we train our users fast, etc.
Now I’ve seen most large organizations totally blow it on this. The controls end up being the goal rather than the effectiveness and cost management. This usually leads to skunk works, or some other form of "cheating" to get things done. Letting the pendulum swing to far that way can actually cost *more* than the Wild West approach.
All organizations should have some sort of guidelines at least, and in most cases, stringent rules. As with SharePoint governance, there’s always a lot of "it depends", but there will be a right set of answers for every organization, and some sort of control is what is going to make the organization succeed in the long run.
You’ve got some very good point here that I can relate to. Having started my career at a defense contractor I can tell you you’re spot on with the notion of big corporations blowing it when it comes to actually giving their people the tools they need to be efficient. We often ran into the situation of having to complete task x with some basic piece of software that only has half of the functionality needed. If I had a nickel for every time I had to install a trial version of an application in order to get my work done I wouldn’t have to work for the rest of my life. When you’re that big of an enterprise and you have that many people, yes it’s difficult to swallow the costs of software licensing. That said, if it takes me 3 times as long to do something because I have to work up icons in Gimp because you won’t buy me Photoshop, that productivity loss in itself justifies the license cost. Any “big picture” CIO should be capable of recognizing that, but alas it never seems to come about.
Usually any good CIO gets this stuff, but the messages get muddled on the way down. Or the purchasing policies are out of the CIOs purview. Or the CIO is too ‘important’ to steer the ship. Basically, systemic failure.
As with any strategy, there have to be regularly watched metrics to ensure that progress goes in the right direction. Edicts without regular course correction almost always fail. The metrics need to be designed to indicate the *right* things, too. One typically useless one: lines of code. Want me to write more lines of code to succeed? I can do that easily, but it’ll probably be crap code.
Big organizations are the ones with the handicaps here. Smaller ones are bound to be more nimble by pure necessity.
I’m glad to know I’m not the only one who thinks GIMP is gimpy…
Excellent arguments for corporate environments. I can only imagine how complex IT has to be in order to be efficient. I had my taste of enterprise when I had a brief stint at Siemens. We used a macro program and relied on it heavily but it was way past it’s trial expiration and became buggy due to this. Would’ve saved a ton of time if the little $30-$40 app was purchased for the team.