Redundancy and wasted productivity in programming

Honestly, how many times do I have to write the same piece of code?

I've been writing software for more than thirty years -- I started very young, really -- and I've noticed a pattern with various languages that I've learned: The same components need to be written over with over with each language. And, an ever-expanding universe of those languages is becoming a drain on productivity.

I started out writing code in C back in the seventies, when pretty much everything was do-it-yourself. There weren't many third-party libraries back then. The introduction of object-oriented programming with C++ was welcome; pretty much the same syntax and low-level control, but it let developers write much more elegant code.

Java fixed most of the issues with C/C++ by eliminating pointers and cleaning up memory management, but programmers were forced to learn a slightly different syntax, and all of the extraneous functions that they were used to had to be rewritten. And while Java's multiplatform capability was useful, it meant that software had to be written for the lowest common denominator of the platforms. But Java certainly hasn't been the swan song of the new language parade.

It seems though that since the early 1990s, there has been an explosion of languages including examples such as Perl, Python, C#, and Ruby (on or off Rails), not to mention tools such as Flash and Silverlight.

This forces companies to pick and choose which languages they support. For example, if you wanted to try Google App Engine, you would need to use Python, because that is the only language the company supports.

It also leads to the need to develop and maintain multiple versions of the same software. I'm midway through converting a perfectly good Java mobile application for the iPhone, which requires me to rewrite it in Objective C. And it means that in future somebody will have to support at least two versions of the software.

With every new language comes not only the need to learn and remember the new syntax -- like remembering if the concatenation operator is "+" or "." -- but also the need to either locate third -party libraries or rewrite those utility functions that you depend on every day. And the time required to do that and maintain it for every language costs us time and results in a loss of overall productivity.

While each new language may provide some previously unavailable feature, that must be measured against the impact of implementing code in that language, the dilution of effort available for the other languages, and the potential costs of switching. Before expending that effort, developers should be sure that the switch is work the risk.

After all, we often forget the lessons that history has taught us, especially in the relatively short history of computer languages. Developers who think they've found the holy grail of short time to market in a language like Ruby on Rails would be wise to look up COBOL, a simple well-used language with an English-like syntax that could easily read and update databases -- 50 ago.

Larry Borsato has been a software developer, marketer, consultant, public speaker, and entrepreneur, among other things. For more of his unpredictable, yet often entertaining thoughts you can read his blog at larryborsato.com.

Join the newsletter!

Error: Please check your email address.
Show Comments

Market Place

[]