IDE 2.0: Lessons from History

Software development at a crossroad


January 14, 2008
URL:http://www.drdobbs.com/tools/ide-20-lessons-from-history/205604526

Jens Eckels is a senior technology writer for Genuitec and he can be contacted at www.genuitec.com.


If asked who fathered the printing press, most of us would cite Johannes Gutenberg, a German goldsmith who in the 1400s brought the Bible to the masses. Very few of us would eloquate that a Chinese man named Bi Sheng invented one of the most influential pieces of equipment in history, and this just before 1050 AD. Few would mention that Bi's original press was made using baked clay characters, and was created and fostered in provincial China (including what is now Korea) for hundreds of years prior to Gutenberg's press.

So why do you not hear about the Chinese press? Why is Gutenberg heralded, but Bi Sheng nearly forgotten? The reason is mostly cultural and rooted in what various people groups value as important. The Chinese highly valued (and to a point still value) the hand-written, artful, calligraphic style of their language, and therefore did not see printing as a highly useful technology. The Europeans focused on mass adoption and rapid dissemination of information -- two very different ways of approaching technological advance.

Similarly, we find ourselves at a crossroads in the software development industry, as evolution and distribution of technology are taking multiple paths. But how did we get here?

Over the last few decades as source code became more complex, it became necessary to develop environments around the "code" so that coding itself was more easily addressed. Thus, an evolution in development tools necessarily made it easier to hand-code with new, "wooden typeset" (to include our printing analogy) toolkits.

As the code got even more complex, we found ourselves juggling a number of technologies to complete the simplest of projects. Evolution again crept in. "Metallic," more complex tools were developed to manage the code-writing process and partition it into segments that were easier to address individually alongside each technology concern. Code completion/generation, color coding, refactoring support, and the like, are extensions of this concept, and this is where we presently live with the majority of IDEs and other toolsets.

Despite these advances, today's enterprise developers spend less than half of their day interacting with code. The rest of the time is spent setting up and configuring their work environment, packaging projects, starting and stopping servers, and twiddling their frustrated thumbs while waiting to see how their application will behave -- all the while pulling their hair trying to figure out which one of the many variables in their environment or technology stack is the source of the endless trial-and-error.

When source code alone is the golden hammer, calls for productivity (getting past the trial-and-error stage) are often answered by writing more code in the form of deployment scripts, configuration wizards, persistence and architectural frameworks, and other automation logic -- all of which have little to do with the project at hand. This turns developers into toolsmiths rather than application engineers. But in an industry where less than a third of projects succeed in meeting their scope, time lines, and budget, can we afford to continue fixating on this art of source in the face of global delivery mandates?

Regardless of their chosen tools, or even the number of them being used simultaneously, the overarching message for and from developers is clear: A favored code management solution/environment is necessary to manage how to code each piece of any given project and environmental preferences, and to manage servers and external data sources. If the environment cannot do this and developers have to toolsmith the productivity gap, most find themselves trapped chasing environmental ghosts rather than focusing on the task at hand. But most importantly, developers lose the one constant factor that has remained steady through all these centuries -- time.

IDE 2.0: The Integrated Delivery Environment

Enter the IDE 2.0. A proper IDE these days needs to be a fully integrated solution that handles all of a project's data from the UI to the data side, and be ultra sensitive to runtime requirements. Without this type of management ability, developers will find themselves spending too much time debugging and error-searching, and less time delivering. The old, siloed, trial-and-error methods of develop, deploy, and debug are becoming less and less economical as the layers of technology get more and more extensive. In short, we have seen a drastic change from seeing code as an "art form" to the desire to "get the job done."

Additionally, in the competitive global marketplace, we can see that skillfully-composed, handwritten source code is not all that is needed in today's projects. Hand-writing, packing, deploying, and testing all of the code necessary takes far too much time and maintenance for developers, and is most likely frowned upon by global executives. Today's developer needs a fully stable, packaged, out-of-the-box solution that allows them to code, test, debug, manage, and play with technology in a single environment with cross-layer management ability, speed, accuracy, and confidence.

"But wait," you might say. "I like having control of my code. I can do it myself and don't need the management features. Plus, when something auto-completes, I don't know what's in it and it may not be the way that I would code it."

It is understandably easy to turn this type of conversation into a "black box versus build-it-from-scratch" conversation as though they must be mutually exclusive options. But this would cause us to lose sight of the forest for the trees. In an IDE 2.0 world, that conversation should not be a debate because the tool should let you "get it done" first, then anguish over the details, rather than debate over the "art" of what it should be at the expense of delivery.

Consequentially, today's developers demand an IDE that truly integrates the developer into their technologies and helps them along the way. Discerning developers need the next generation of developer environments using today's best, ever-improving technologies.

What are the consequences of ignoring this IDE 2.0 phenomenon?

China at one point passed on the power of emerging, fast, behavior-changing technologies in favor of a simpler, more artful existence. That was a choice they made, and a very deliberate and noble one. The art forms they created are still admired to this day as some of the greatest in the world, and their culture is inarguably among the richest in history. However, the Renaissance economies of Europe and the New World that emerged as a result of the printing press' mass adoption and evolution changed the global marketplace forever and set new standards for technology and commerce that are still felt to this day.

Will today's software developer be marketable tomorrow by choosing art or productivity? We will see.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.