Steve Roman is a Professor of Mathematics who entered the world of programming and technical writing when, in the mid '80's, he needed to change the menu structure of WordPerfect version 2. He's now the author of four VB programming books for O'Reilly, as well as over twenty-five others (for other publishers), most of which deal with advanced mathematics and programming topics such as algebra, combinatorics, graph theory, and applied mathematics. Steve brings an intriguing perspective to VB and programming in general, one that makes his books especially popular with his audience and which he discusses quite eloquently in this interview.

McGoldrick: Let's jump right in, Steve. What led you to write Learning Word Programming, Access Database Design and Programming, and your current project, Learning Excel Programming?"

Roman: Microsoft Word and Excel are very powerful and complex applications. To achieve a more-or-less complete level of control over these applications, you need to program them. The object models that are used to program Word and Excel are the most complex that Microsoft has to offer and there are several places in which they are, shall we say, less than intuitive. This prompted me to write books about these object models and how to program them. I hope the books will provide a useful learning tool and reference for both new and experienced programmers.

With respect to the Access book, there are other issues involved. The Access and DAO object models (DAO is the programming arm of the Jet Database engine) are not terribly complicated. But unlike Word and Excel, when developing an Access application, the issue of database design is very important. A poorly designed database can quickly grind to a halt with even a modest amount of data. Thus, I wanted to write a book that gave a general introduction to database design principals as well as a discussion of database programming.

McGoldrick: But that's not the end of your O'Reilly bibliography. You also wrote Developing Visual Basic Add-ins. What led to that?

Roman: These days, I spend most of my working hours sitting in front of the computer, either writing books or doing Visual Basic programming for myself or my consulting business. Accordingly, I consider it important to remove as many distractions as possible between me and the creative part of my work. This is precisely why I like to customize the applications that I use. By setting up these applications to suit my particular working habits, I can get "closer" to the work itself. The Visual Basic IDE is not very customizable through menu selections, but it is highly customizable through add-ins. Moreover, the VB IDE add-in object model (officially known as the VB Extensibility object model) is almost totally shrouded in mystery. I couldn't resist the challenge of explaining this model and how to use it in a productive way.

McGoldrick: Tell us about your background. How does it relate to all these books?

Roman: By profession, I am a Professor of Mathematics, although perhaps I shouldn't mention it because I would not want anyone to get the impression that my computer books are mathematical in any way. The reason I mention it is to make the point that I have been a teacher for over 20 years.

On the other hand, I have been programming PCs since the mid '80s, first in assembly language and subsequently in various versions of Visual Basic (and a little in Visual C++). While I have written a few stand-alone Windows applications, such as a file management program and an object model browser, most of my programming has been for the purpose of exercising greater control over either the operating system itself or over someone else's application.

In fact, I started programming in the mid '80s in order to change the menu structure of WordPerfect version 2! In those days, I was writing math books and needed to do a lot of subscripting and superscripting. WordPerfect's subscript/superscript feature was buried under a few levels of keystrokes but I wanted to simply assign these features to the F9 and F10 function keys. So I learned assembly language programming just to trap the keyboard and change the meaning of these two function keys. This is how my programming career started.

McGoldrick: What's the most difficult part about documenting technologies like these?

Roman: The most difficult portions of a book to write, and this is true of all my books, are the portions that have little or no documentation. This puts me in the position of having to experiment and draw empirical conclusions. I enjoy doing this, but it always leaves me wondering whether I have been able to deduce the full story. On the other hand, if Microsoft carefully and completely documented all aspects of their products, there wouldn't be much need for people like me to write third-party books, so I'm not complaining!

McGoldrick: What are the biggest problems developers face when working with VB add-ins?

Roman: Microsoft has thoughtfully provided VB add-ins to allow us to customize our working environment. Unfortunately, they have not brought this model to the forefront in their documentation. As a result, the documentation is sketchy and the subject of creating add-ins appears confusing, even though it is not. As a result, the greatest difficulty when working with VB add-ins is simply learning what can be done with the VB Extensibility model and how it can be done.

Actually, this is somewhat of an irony. In a perfect world, the most difficult aspect of, say, creating VB add-ins, should be the creative part, that is, thinking of clever add-in features and ways to implement them. It should not be having to deal with what this or that property or method really does because it is not carefully and clearly documented.

McGoldrick: What are the biggest problems would-be developers face when working with introductory VBA programming?

Roman: In my view, the most important thing for a would-be VB/VBA developer is to get some proper initial training, not only in the language itself but also in good programming habits. From that point on, all that should be needed is a decent reference book (online and hard copy).

Now, there are plenty of books on introductory VB/VBA programming of one sort or another. However, the alarming trend in computer trade books in general is to create massive 1,200-1,500 page tomes that do little more than take a portion of Microsoft's documentation and clutter it up with anecdotes, jokes, and unnecessarily lengthy examples.

The problem, in my view, is sadly quite simple: Most authors of trade programming books are not trained writers or teachers. Also, most publishers (O'Reilly seems to be an exception) don't seem to care about the quality of their offerings. Rather, they seem more interested in the size of their books and thus in how much space they will take up on the bookstore's bookshelf next to competing books. Have you ever noticed how difficult it is to find the name of the author on the cover of most of these books? I guess most publishers figure that if one person doesn't write the book, they can always find someone else to do it -- perhaps a passer-by peregrinating by the publisher's offices! Let's face it, after several rounds of technical editing and copyediting by numerous editors, all these books tend to reach the same level of banality anyway.

McGoldrick: The body of information that programmers need to master seems to be increasing geometrically. Over the next few years, how do you see the kinds of information that developers need (and particularly the kinds of information that you've written about in your O'Reilly books) changing?

Roman: I think that we are facing an increasingly serious problem in this regard as the years go by.

As you suggest, the complexity of PC applications and PC programming is increasing dramatically. I have a suspicion that a good portion of this increased complexity is due to the fact that software companies simply pile on new features as they release new versions of their applications, without taking the time to simplify and cleanse existing code. Of course, the market is terribly competitive and such endeavors take time and are probably not perceived by software executives as providing any real marketing advantages. Can you imagine Bill Gates directing the Windows programming team to stop adding new features to Windows for a year and just concentrate on streamlining and cleaning up the Windows code, so it will run more efficiently and crash less often? Can you imagine the Windows 2000 box saying "This version offers absolutely no new features over the previous version but it will not crash as often"?

I do not mean to suggest that this is the only problem. Of course, as new ideas come to the forefront, computer operating systems and applications will necessarily get more complex. I do have a suggestion, but I hesitate to mention it because I don't think it will be at all popular.

McGoldrick: Go ahead.

Roman: There is one area of human knowledge that is at the same time the most complex of all areas of human knowledge and also the most organized and carefully documented. It is mathematics. Trust me, the area of mathematics known as Field Theory is far more complex than the Microsoft Windows operating system could ever be. Yet it is far more carefully and precisely documented, and this is precisely the reason that it can support this complexity. Field Theorists can communicate with one another based on a common ground of carefully documented ideas.

To illustrate, if you ask ten different Windows programmers to describe a COM interface, you will probably get ten different answers. But if you ask ten different mathematicians what a Galois group is, you will (or should) get the exact same answer from each one (using different words, perhaps)!

If you ask me (and you did), the best thing that Microsoft and other software companies could do is to start a careful program of precise documentation, using a style that is typical of the mathematical approach. Only when all ten programmers give the same response to questions such as "What is a COM interface?" will the notion of a COM interface be maintainable as the years go by and as the level of complexity rises. If everyone continues to have their own "opinion" about COM interfaces, then sooner or later the whole business will come crumbling down under the weight of more and more variations on a single theme.

McGoldrick: You're a really good technical writer. Do you have any projects not related to O'Reilly?

Roman: Yes. In the area of personal computing, aside from my four O'Reilly books, I have written two other computer books Concepts of Object-Oriented Programming with Visual Basic and Understanding Personal Computer Hardware, both published by Springer-Verlag of New York. In addition, I have written a couple of articles -- one on programming the Windows mixer applet in order to programmatically control PC speaker volume and one on technical desktop publishing.

In the area of mathematics, I have written 25 books (including a book in Field Theory, by the way) and about 20 research articles in the areas of algebra, combinatorics, graph theory, and applied mathematics.

McGoldrick: That's really impressive! In addition to the books you've written for O'Reilly, you've also developed the Enhanced Object Browser, a hierarchical object browser that will be included with the titles in the Programming the Object Model series. What led you to develop the object browser?

Roman: As I mentioned earlier in this interview, the Word and Excel object models are very complex. In fact, the Word model has almost 200 objects and over 3,000 properties and methods and the Excel object model is similar. Also, some of the smaller models, such as the VB Extensibility model and the ADO model, are not very well documented. For these reasons, we programmers really need a useful tool for exploring object models. Microsoft's object browser ignores the most important aspect of object models -- their hierarchical structure. My object browser gives a two-dimensional tree-like view of object models -- one that can be customized in various ways. I think this makes it a much more valuable tool.

To be sure, creating such a browser presented several logistical challenges. For example, a single object can appear in many places in a model and most models are circular in nature. This poses the problem of determining how much of the model to display at one time. It also involved making ad hoc changes to each object model, since the type libraries used to create the models do not always make it clear when one object is a child of another. As usual, I enjoyed the challenge. I used the browser extensively to help write my books on programming the Word, Excel, and VB Extensibility object models.

McGoldrick: One last question: If you had the opportunity to ask Microsoft to change one thing about Visual Basic, what would it be?

Roman: Allow me to change this question a bit and comment on a few VB features that I think need changing or at least careful watching.

1. Visual Basic should produce concise stand-alone exe files.
The other day I needed to create a simple application that would open an Access database and change a single field value in a single table. The program is precisely 12 lines long. However, the VB setup wizard produced no less than 3.5 megabytes of compressed files in support of this 12-line program! So much for distributing this on a floppy diskette.

2. VB should provide better support for Windows system programming, in particular by supporting more data types and more pointer-related code (beyond AddressOf).
I realize that this can be counterproductive. It is probably not the direction that Microsoft wants to take VB, especially since it might impact the number of users of VC++. Nevertheless, a little bit more help in this direction would be a great help for us VB hackers.

3. There is nothing more wasteful and frustrating than dealing with the tiny dialog boxes and drop-down list boxes that appear in most Windows applications.
I use a 21-inch monitor running at 1,600 by 1,200 and I suspect that most programmers use at least a 17-inch monitor running at 1,024 by 768. In any case, on my monitor most dialog boxes barely fill one-quarter of the screen, forcing me to painstakingly scroll through list boxes looking for an item. Why doesn't Microsoft (and others) implement dynamic dialogs that adjust their size according to the resolution of the display? Dialog boxes are generally modal, so who cares whether they obscure the underlying window? I'd like my dialogs to span the entire height of the screen. They may not be pretty, but they would be more effective. This applies, for instance, to the Object and Procedure drop-downs located just above the VB code window. (I have been slowly working on a utility that will expand an application's dialog boxes to full height.)

4. I am very worried about the new trend in VB help, namely, incorporating it into Visual Studio help and thus combining it with C++, J++, and other help systems.
The initial release of Visual Studio 6.0 help has some characteristics that still have me in a state of disbelief. For instance, aside from the fact that Properties and Methods list boxes are tiny, I couldn't believe my eyes when I saw that the items in these list boxes are not always alphabetized! This is almost enough to keep me from upgrading to Visual Basic 6! I hope that Microsoft takes a careful look at its help strategy. I see nothing wrong with using compiled HTML as a help file format, provided it is implemented wisely.