From the Editor - February 1996In the "old" days, if you were a Clipper developer, a Cobol programmer, or a SQLWindows jockey -- you were the star of the show. Learning the syntax and semantics of a language represented a signficant barrier to entry; therefore, those who jumped the barrier could bring a lot of value to their companies and clients. Today, as we are inundated with "visual" tools and reusable components, programming skills -- and the languages themselves -- have become devalued. Forces in the software market and in the user community are changing the way we think about application development. It's not enough to be an expert coder or produce an elegant or fast programming language. The "value-added" to development comes not in programming, but in not programming.
While we still see niches for value-added language products -- such as Borland's Delphi with its high-performance compiler or Sybase's PowerBuilder with its easy-to-use DataWindows -- we see a steady commoditization of language platforms. We're beginning to see modeling tools that generate VB, or C++, or PowerBuilder PowerScript -- whatever you like -- so that it matters less which language you use. Instead of being identified as VB or Delphi shops, a company might become an LBMS, Popkin, or Logic Works shop.
When developing applications for Windows in particular, the operating system levels the playing field in terms of functionality and performance. Because the languages rely on Windows' APIs for so much of their operation, it's hard to differentiate the runtime characteristics of one language from another. No language solution running under Windows can be any more robust than Windows itself. There's no magic. Moreover, if you mix and match OLE components, for example, the choice of development language becomes irrelevant.
Although it might seem that Microsoft is driving the devaluation of languages (with VB the only language left standing), the trend is inevitable: Businesses need to slash development time to meet the demand for applications. Because we've already wrung the last bit of productivity out of programming as we know it (object-oriented or otherwise), we need to look elsewhere for productivity gains.
Component development -- the assembly of applications from large chunks -- offers only a partial solution if programmers must continue to hand-code every component. Instead, application builders need to start exerting 90 percent of the development effort to create language-independent models of the data and the business processes. Then they can apply the remaining 10 percent to transform those models into working components. Today, the last bit of code still takes the most time to produce.
As languages become commoditized, the data- and process-modeling technology (and associated repository tools) will provide the real added value in development tools. As such, developers who remain pure coders and vendors who adopt a language-centric tool strategy face an inevitable erosion of their respective market values. Don't get left behind.
Your letter must include your full name, address, daytime telephone number, and e-mail address. We ask for this information so we can verify a letter's authorship. Unless you state otherwise in your message, your Letter-to-the-Editor becomes the property of DBMS, and you grant permission for us to use it on our Letters Page along with your name, city, state, and e-mail address.