Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


IDE 2.0: Lessons from History

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.