Author Interview: Robert Glass

Robert Glass has been called "The Mark Twain of the computer industry". He's a prolific writer (over 25 books to his name), a respected veteran of the software development world (over 50 years in the industry), and respected observer in the field (editing, writing, and publishing articles, newsletters, and journals). The best part is that he agreed to trade emails with me to do this interview. Our conversation ranged over many topics, and I've assembled the best parts here. Happy reading!

Writing & Publishing

You're a tremendously well known and respected author, but you've chosen to publish updates of two classics, Software Conflict 2.0 and Software Creativity 2.0 , with a small publisher (developerdotstar). Why?

Bob: It is certainly true that, once you have published a book, the established publishing houses are more likely to publish your next one. But that doesn't mean that everything you write after that first one is automatically going to be accepted by them. Some of my recent contacts with established publishing houses have been less than satisfactory, especially after my long-time favorite editor departed from the one I'd used most. Given all of that, I was ready to try something new.

I was very pleased when developerdotstar wanted to republish some of my older books that I thought were pretty good ones, and it was fun thinking about striking out in a new publishing direction with an "indie" publisher.

How has the process of writing and publishing been different with these two updates versus the originals?

Bob: It's very different. In a sense, while doing these 2.0 books, I'm my own reviewer and critic, going through my old work and figuring out how I'd like to now do it differently. That's vastly different from creating original content. I remember very well why I said what I said in those older books; the only issue is, is it still correct, and if not what should I do about it? So it was actually quite a bit of fun to do version 2.0s.

What kinds of changes do you see on the horizon for the technical publishing space? Do you think technological or societal forces are driving these changes?

Bob: I don't do forecasts. My belief is that, in a fast-paced field, they're nearly always wrong. I've been known to poke fun at futurists in my day for their out-on-a-limb predictions, and I've made up my mind that I won't be caught out on the same limb.

How should a reader like me approach Software Conflict 2.0 differently than, say, a book about a programming language or a programmer's blog?

Bob: I'm hesitant to tell readers how to approach anything. I personally read to enjoy and to learn. I hope my book is both enjoyable and a learning experience. My picture of such books as those on a programming language is that they are about "how to" do something, and are much more about learning than enjoying. I don't find myself reading many of those, but if I were a novice in the field, or eager to learn about something new, then that would change.

Regarding a blog, my answer would depend on the blog. I can imagine many of them are read more for enjoyment than for learning. I would be hesitant to learn from a blog unless I believed in the expertise of the person writing it.

Programming, Software, & Languages

If someone told you they wanted to move beyond being a journeyman programmer and master the craft, what advice would you give them?

Bob: Business knowledge: Read everything the company produces on its business. Get to know as much as possible about the work of your immediate customers and users. Understand why the solutions they ask you to create are important to them. Begin to think in terms of possible problems/solutions they haven't posed to you yet.

Technical knowledge: Shadow the top technologists in your organization. Understand what they do, and how they do it. Read the code they produce and read their documentation of that code. Keep up to date with the relevant technical literature in your field. Read at least IEEE Software and Cutter IT Journal and Software Development. Read relevant books. Attend user groups for products your organization is involved with. Attend practitioner-focused conferences on relevant subjects.

If you had to sum up today's state of the art from the perspective of someone who experienced software development in the sixties, seventies, and eighties, what would you say are our best and worst traits.

Bob:Best traits? The depth and quality of available tools. The Agile belief in people over process. The Open Source focus on fun over duty.

Worst traits? The "us vs. them" mentality which causes today's programmers to see themselves as a separate and competing breed from yesterday's programmers. The tendency to reinvent wheels. The belief in Agile processes as being good for all problems. The hyped belief in Open Source as the best of all possible ways of building software.

Mark Jason Dominus recently wrote in Design Patterns of 1972 that

"Patterns are signs of weakness in programming languages."
"When we identify and document one, that should not be the end of the story. Rather, we should have the long-term goal of trying to understand how to improve the language so that the pattern becomes invisible or unnecessary."

You're in a pretty good position to weigh his thoughts. Do you think we're focusing too much on practices, patterns, and tools and not enough on fixing out languages to do the right thing?

Bob: I don't see languages as the be-all end-all. But I have to admit this is a new thought to me, and my reaction is kind of off-the-cuff. I guess my strongest belief, given that, is that patterns are about design, not programming per se, and therefore it's not clear to me that patterns should be built into programming languages. If I were to voice an opinion about what should be happening in programming languages, it would be to build in more domain-specific stuff to solve particular classes of problems, the result being domain-specific languages. Most patterns to date are domain-independent (that's meant as a criticism), which means that incorporating patterns into languages does nothing to further domain-specificity.

. . .Certainly, he's right in that subroutines, which date back into the 1950s and into assembly language, eventually were embedded in programming languages. Whether that's evidence that other patterns should be similarly embedded, I don't know.

How far down the path into domain specific languages do you think programmers should be walking? Is the growing popularity of writing a DSL for everything going too far?

Bob: I'm a deep believer in domain-specific languages, but I think researchers should be leading the way through this particular minefield, not application programmers. Application programmers have far more pressing tasks than inventing languages.

Language design should be done by skilled and knowledgeable language designers. The big problem is that today's language designers don't care about / aren't interested in, applications, so they're unlikely to help us out in the near term.

I do think, however, that in the ancient past, when COBOL and Fortran (which are the original domain-specific languages) were in full flower, we understood the role of languages vs. applications better. You may wonder why COBOL, for example, has survived all this time when almost everyone says it's a very bad language. It's because it has business-domain-specific capabilities that today's languages still don't offer, like decimal arithmetic and heterogeneous data/file manipulation. I think one should start with the dominant domains, then figure out what language features they need, rather than start with neat language features or compiler tweaks, and see who they should be good for

Many people today are making languages decisions emotionally instead of rationally, this even extends into language advocacy. Do you see this a new development? What would you recommend as an antidote?

Bob: This is all part of something I call "local loyalties," where we choose up sides on some issue. It's a natural tendency, now and forever. Examples are not just choosing a programming language, but choosing an operating system, or Microsoft vs. Open Source, or Ford vs. Chevy, or (in my time) IBM vs. the "Seven Dwarfs" (IBM's relatively powerless competitors of the time). I can remember, in one of the first books I wrote, being asked by a reviewer to choose to create an example using "a text editor I loved" (I responded that I didn't love text editors, I considered them tools). Obviously, that reviewer expected me to have a local loyalty for a text editor.

What should we be doing instead? Ideally, we'd choose a programming language because it was best suited for the problem we needed to solve, or to the organization in which we work. The latter makes for an easy decision; the former is hard, because researchers have done a poor job of linking tools/methods/languages to problems.

Books

It looks like there's a growing (renewed) interest in Software Conflict and Software Creativity. Why do you think that is?

Bob: I'm uncomfortable with questions that ask me, in some sense, to brag! But what the heck ... I think these books are going well because

1. They contain a sense of timeless relevance.
2. They're fun reading.
3. They provide honest insights, calling a spade a spade.

Why do you think a novice or journeyman programmer should pick up your books? What will he learn from them?

Bob: Novices? They provide a 5000 foot altitude view of the field that many other books, down at ground level, don't provide.

Journeymen? They provide a sense of "this author has been-there, done-that" relevance that resonates with them.

What books (technical or not) are on your list to read right now?

Bob: Since i live in Australia now, I'm reading quite a number of books about my new country. Peter Dornan's books on Australian participation in World War II are great non-fiction action books. That's what's on my reading table right now.