Columns
IT culture conundrum
- By Barry Zellen
- June 1, 2001
Which comes first: a technology or its culture? While not as widespread a conundrum as the chicken and egg metaphor, it is an interesting question. Just as chickens come from eggs, which come from chickens, technology seems to spawn its own technology culture, while at the same time appearing to be borne of that culture.
This ambiguity is nicely illustrated by component-based development (CBD). Our cover story, "Approaching the promised land of component reuse," by Ivar Jacobson and Martin L. Griss jumps into this riddle of technology and culture. The authors believe we are on the threshold of economically significant component reuse, as the technology and standards needed to support CBD are finally in place. The technology, long-expected by a forward-looking culture, has come of age. Before this convergence, "the benefits of large-scale CBD [had] been hampered."
In "Changing IT culture: Can component management tools make a difference?", I examine some component management tool makers on the market—ranging from Select (whose acquisition by Aonix was announced in April) to newcomers such as Intellect Market and Objectools. Select's well-known financial misfortune illustrates the ambiguity of technology and culture. In Select's case, its component management technology emerged before the culture it required to sustain it. Contemporary component management tool makers and vendors hope their timing is better and that the culture has caught up.
First-time ADT columnist John Murray, in his "Component counterculture: The politics of software development," sees culture as the cause of continuing resistance to CBD. He writes, "dealing with and eventually overcoming that resistance is a cultural and political issue rather than a technological one."
This issue examines other aspects of IT culture. Frank Teti, in his "J2EE bridges the legacy gap," examines how technology and solid architecture can prevent a clash of cultures as companies implement e-commerce initiatives and integrate their legacy systems with the 'Net.
Ulrich Eisenecker and Krzysztof Czarnecki, in their "Automating software development with the system family paradigm," predict programming languages will evolve to be replaced by "an ecology of abstractions," allowing increased automation of the development process—transforming development culture.
And John K. Waters, in his "Linux gladiators duel for the desktop crown," visits the battle lines drawn between the GNOME and KDE communities, pitting free software culture against the open source movement.
Getting back to my original question, "Which comes first: technology or culture?," the answer now seems obvious. Both are part of an evolving continuum. Like chickens and eggs, they are involved in an ongoing process of generational change and transition.
As always, it has been a pleasure. See you around.