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.