Developing Trends: One Tool Doesn't Cut It

And yet I hear this kind of narrow-minded argument in enterprise application-development departments quite frequently these days. It's almost as if people who are totally sensible in their personal lives become thoroughly daft when they step foot in the office. If I hear one more CIO claim, from the bottom of his or her heart, that the development staff should only have to know one language, I'll lose what little self-control I have left.

Hone Your Craft

Programming is like any other craft--the more you know about it, and the more hands-on experience you have with it, the better you tend to be at it. IT professionals who have studied compilers and operating systems don't apply all they've learned every day, but they have a knowledge base that others lack. It's easier to decipher a problem with source code if you have some idea what the compiler or interpreter is doing. And those who know more than one language tend to look at problems from more than one angle--they're not stuck in a single mind-set, so they can typically deliver solutions that address business needs more quickly.

You'd think we'd have learned by now. We've seen this attitude in application development before. Remember the COBOL-to-VB conversion? How about the transition from Assembly to C in the embedded space? Or the seismic shift from structured to object-oriented programming? I remember (unfortunately).

Many organizations lost some very good people during these conversions because they just weren't prepared to make the necessary adjustments. And there's plenty of blame to go around: Employers should have offered and encouraged training in alternative platforms and languages, and employees should have pushed to learn more about their chosen craft.Twisted Logic

I understand the perceived benefit of limiting the number of languages used in an IT organization. The consistency makes for more mobility between projects and reduces costs for application-development tools. But it also binds your hands and forces your developers into a rut. With a single language, it's easy to say, "We always do it this way--no ifs, ands or buts." It's also easy to say, "We can't buy that product; the programming API doesn't speak our language."

But that approach isn't in the best interest of the organization as a whole. As specialists in application development, it's our job to offer the best possible solutions to our clients' business needs. And as managers, it's our responsibility to be sure our staffs are equipped to follow through. We must give current employees the opportunity to learn and use additional skills, or we must hire new people with broader skill sets, or both. Anything less and we're putting our own jobs in jeopardy.

Given the growing number of platform and application options, attempting to use a single programming language for every development project is as productive as trying to use a Sawzall for every carpentry job.

Don Macvittie is an applied technologist at WPS Resources. Write to him at [email protected].Post a comment or question on this story.