Last month, David Kalman announced his promotion to publisher of DBMS, and he has asked me to succeed him. I am honored to be DBMS's new editor. David Kalman shaped DBMS into an outstanding publication for professional developers and managers of client/server systems. My goal is to maintain the high standards Dave set, while keeping DBMS fresh, informative, and insightful. Of course, DBMS must evolve with the industry, but there is no immediate need for radical changes in scope or direction. DBMS will continue to tackle fundamental database and application development issues while also exploring emerging trends and technologies.
As editor, I am ultimately responsible for DBMS's content and quality. But I don't accomplish this alone. My co-workers Theresa Rigney and Clara Parkes play vital roles on the DBMS editorial team, and I'd like recognize and thank them. Theresa shepherds our feature articles from conception to completed manuscripts, and she also conducts many interviews. (Theresa also edits our sister publication, OTJ, a technical journal for Oracle users.) Clara coordinates our product reviews, sifting through mountains of new product announcements to identify what we will cover. Many other hard-working staff play equally essential roles, and I'll tell you more about them in future columns.
Becoming editor has heightened my awareness of the skyrocketing complexities that today's developers face. The volume of technical information that a competent developer or manager must master continues to expand. I wonder how long this trend can continue before the burden of keeping up overwhelms a developer's ability to get real work done.
For example, let's say your company relies heavily on Microsoft products. Over the last 12 months, you have had to absorb a dramatically new and different operating system (Windows 95), DBMS (SQL Server 6.0), and development tool (Visual Basic 4.0). You may also have looked at Access 7.0 for Windows 95 and Visual FoxPro 3.0. (Throw in a peek at Delphi or PowerBuilder and a CASE and testing tool just to keep your weekends interesting.) And if you didn't divert significant time getting up to speed on the Web, you now have a big hole in your skill set. How long does it take to become productive with, let alone master, one major upgrade or new product? In any given year, a client/server developer is likely to face three or more such changes.
Sure, new products simplify many previously difficult tasks, but new expectations promptly fill the void. In 1986, writing light bar menu programs was hot stuff. Today we take that for granted while deciding how to allocate system functions to distributed objects. In 2006, we'll wrestle with issues that probably don't even exist today.
I'd be naive if I told you DBMS alone could conquer these complexities. You can help by letting me know what your burning issues are. Write to me at mfrank@mfi.com or at 72167,736 on CompuServe. Better yet, why not write for DBMS? Readers often make the best contributors, and we will work with you if you have never published before. You can find Writer's Guidelines on the DBMS Web site (http://www.dbmsmag.com) and in our CompuServe forum (GO DBMS and download writguid.txt from library section 0).
If you subscribe to DBMS, your January issue included the 1996 DBMS Buyer's Guide and Client/Server Sourcebook CD-ROM. This disc is packed with free software from Oracle and Powersoft, plus product information and demonstrations. It even provides an index of DBMS articles. Take the time to install and browse through it; you might even win $500 for your efforts.
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.