Canadian Information Processing Society

 

CIPS logo

 

 

 

CIPS Connections -- Current Articles

1/10/2003 8:52:52 AM
Development Expert David Conger
Interview by S. Ibaraki, I.S.P.

This week, Stephen Ibaraki, I.S.P., has an exclusive interview with noted development expert and independent consultant, David Conger.

David is a 20 year veteran in open source, network programming, computer graphics, C, C++, C#, and Java. He has written the documentation for numerous technologies from Microsoft, authored several books on programming plus worked in education as a professor of Computer Science and Business Computer Programming.

Discussion:
Q: You have such a long and distinguished career in computing. Thank you for agreeing to this interview and sharing your insights and years of experience with the audience.
A: Well, thank you for this opportunity.


Q: Your experiences as a respected and widely known guru would be of benefit to many veterans. Can you detail your personal history and how you came to write? What personally prompted you to enter the computing field? What led you to becoming a noted expert on application development?
A: I got into computers the first opportunity I had, which was in college. I graduated from high school before most high schools gave kids access to computers. My first term in college, a friend of mine advised me to take a BASIC programming class. He had taken it the semester before and told me, "You'll love this stuff." Less than a week into the course, I knew that I'd be doing something in computers for the rest of my life. In less than a year, I got my first contract programming job to help me pay for school.

Interestingly enough, my parents actually had a tough time understanding the value of what I was doing. When I went home for the summer, my father (an accountant) told me, "You won't go into business, you hate selling things, you got a bad back (from an injury in high school) so you can't dig ditches or do construction, what else is there?" A year or so later, he computerized his office with IBM XTs. I instantly became his tech support center, even though I was thousands of miles away. He never questioned my choice of major after that.

Over the years, I've focused a lot on graphics and network programming. Early in my career, I wrote firmware for parallel processing, real time graphics display controllers used on the F15E fighter jet and the OH58D military helicopter. I also spent some time as a game programmer for a company called American Laser Games.

Writing was something I thought I'd never do. In fact, a few years ago, my father reminded me that I used to complain about having to take English in high school and college. I used to say, "Why do I need this stuff? I'll never be a writer!" Famous last words.

I was encouraged to become a writer by a college professor of mine. I was taking a class in Asian humanities at the University of Hawaii. The professor, J. P. Sharma, liked to have us analyze Asian folk literature and explain what it showed about the people who originated it. So in each paper, I would tell the story in my own words, and then present my analysis. The professor had a young daughter that came into her dad's study one day to see what he was doing. She pulled my paper off the top of the stack on his desk and began reading. He told me that she so enjoyed the way that I retold the stories that, from then on, any time he came home with assignments, she would go through the stack to find my paper and read it. Professor Sharma encouraged me to write a collection of folk tales instead of the final paper. When I did, he encouraged me to get them published. That became my first book, Many Lands, Many Stories.

I set writing aside until the early 1990's. While I was teaching, I was asked by a publisher's representative to submit some of my class materials to possibly be developed into a book. Shortly thereafter, I got contracts for 5 programming books. A few years later, that led to a contract job at Microsoft, where I wrote documentation for many of their graphics and networking technologies.


Q: What are your personal goals 1, 3, and 5 years into the future?
A: My number 1 goal is to invent a time machine, go back to the mid 80's and beat my younger self silly for selling all my Microsoft stock. If I hadn't, I'd be retired.

As far as goals for the future, well, I think my biggest priority has to be what it's always been – to stay on top of things. In this industry, you have to keep learning constantly or you're obsolete in a year or two. When I was teaching, I used to read about 1500 pages a month of computer books, plus articles from about 2 dozen computer magazines in our school library. These days, I don't read quite that much about computers. Maybe it's age, but I've branched out into things like religion, philosophy, history, languages, and music.

In addition, I'd like to make a bigger contribution to the Open Source movement. I can't discuss the details, but I'm currently in the process of setting up something that I think will give a big boost to a couple of specific Open Source projects and to Open Source in general. I'm having to convince certain companies that these projects are not as “out there” as they might seem at first. They're reluctant to be the trail blazers. If things go well, I should have something out this time next year. If so, that's where my energies will be focused for the foreseeable future.


Q: What ten career pointers would you provide specifically to people who wish to enter the computing field?

A: I could only come up with 8, and here they are:

  1. Tinker, tinker, tinker. When you get new hardware, software, or a new operating system, tinker with it. Stretch it to its limits and beyond. Be curious. That's how you become an expert.
  2. Never stop learning. You'll go obsolete if you do.
  3. Find mentors. I didn't have many. It made my road a bit rougher. Find someone knowledgeable and pick their brains as often as possible. Watch what they do to stay on top of their game. Do the same thing.
  4. Develop backup plans for your career. With the uncertainty of today's economy, you never know how the industry is going to change. The dot com bust is a prime example. The bubble burst, and suddenly thousands of people were out of jobs. Plan what you'd do if you lost your job. Where else could you apply? Where would you relocate to? Besides the type of company you normally work at, who else could use your skills?
  5. Be versatile. Miyamoto Musashi was possibly the greatest samurai warrior that ever lived. He taught in his Book of Five Rings that a warrior should never have a favorite weapon. To be a great warrior is to be versatile in all weapons. The same idea applies to a computing career. Computing is an extremely flexible field. You can be a developer, tester, writer, go into sales support, be a network administrator, web site administrator, etc, etc. Think flexibly. Develop backup skills sets so that you can jump into something else if you have a career setback in what you're doing.
  6. Don't get religious about technologies. By that I mean, don't be too proud to use a particular technology. This goes along with #5. As an example, ask the average C++ programmer if he'd mind writing you a program in Visual Basic. When he finishes either choking or laughing (or both), ask him why he feels the way he feels. He'll probably have great technical reasons why he doesn't want to use VB. Nevertheless, there are some perfectly valid reasons why a business would want a program written in VB (many do). You can't always use the technology you like best. Do yourself a favor and be relaxed enough to go along with things until you're in a position to make technology recommendations or decisions. If you get too emotionally tied to a particular technology, programming language, or whatever, you can get a bad reputation in a company. I've seen excellent programmers shoot themselves in the foot this way.
  7. Develop alternate skill sets. If you want a successful career, you've got to have something to fall back on. That can be something in computing, or something completely different. I know of a guy who, when he was laid off from a development job and couldn't find another, entered the ministry in his church. For years, he studied his religion as well as computers. In his spare time, he began developing software for churches and charitable organizations. I know another guy who got a teaching certificate in his state. He substitutes as a math, science, physics, and programming teacher in high schools to supplement his income from his consulting practice, which is suffering these days. These guys have found other ways to apply their skills and developed skill sets outside of computing.
  8. Get as much education as you can. Although you can get into computing without a degree, you'll find much better opportunities if you have at least a Bachelor's. Don't stop studying when you graduate. Get additional certifications from important organizations. These can include the ACM, Microsoft, Oracle, Red Hat, IBM, and IEEE. There's no doubt about it, degrees and certifications open doors for you that would otherwise be closed.


Q: Can you comment on the open source movement and where it’s heading?
A: Open Source is an interesting sort of an animal. It's democracy in technology. I strongly support it. However, I'm going to be a bit critical for a moment and say that too much of Open Source is about Microsoft. Open Source may or may not be the "Microsoft-buster" that so many want it to be. And anyway, MS isn't any more the Evil Empire than say Oracle, or any of the other big players in the industry. I had to laugh when Judge what's-his-name stated that Bill Gates had a Napoleon complex. Well, duh. That's how he got where he is today. All of the heads of big companies have Napoleon complexes. So what? What's that got to do with technology?

Open Source needs to be about technology, not personalities. It should be about innovation, not attacking a particular company. In my opinion, a well-crafted technology is truly a thing beauty. It's a work of art. Because of business pressures, there is not enough opportunity in our industry for developers to be artists at what they do. Open Source gives us that opportunity. I honestly think that the business needs of a company often result in the production of inferior technology. Open Source divorces technology from business necessities and gives those of us who love development a chance to craft something that is actually innovative and unique.

One trend in Open Source that disturbs me is the tendency to just copy whatever Microsoft is doing. Although I can see definite value to .NET knockoffs such as Mono (http://www.go-mono.com), I don't think it's the best use of Open Source resources. In my opinion, it's better do use the freedom that Open Source provides and develop better technologies that provide the same functionality. A good example is the DotGnu project (http://www.dotgnu.org), which provides the same functionality as .NET, but does it using an architecture that's much more open.

In the short term, the bad economy may prove a boon for Open Source. Why, for instance, would anyone pay $125/copy for an office suite when they can get OpenOffice (http://www.openoffice.org) for free? I use OpenOffice all the time. Writer, which is included in OpenOffice, is a great word processor. I write books with it. I wanted it on CD so I ordered it from a distributor. It cost me $16, including shipping. It saves to MS Word format when I need it to, so I can collaborate with people using Word.

In the long term, Open Source needs to focus more on the developer and the end user. We need Open Source tools that are as good as or better than what commercial companies provide. Although there are some excellent efforts going on, I really don't see a development suite that's a strong competitor for Visual Studio, for example.

On the end user side, there's not near enough documentation for Open Source projects. The documentation that exists is woefully inadequate. Open Source teams need to do more to attract professional writers. Having the developers write the docs just doesn't cut it.


Q: You have your finger on the pulse of future trends. For those who have long established careers in computing but wish to change, what ten computing areas would you recommend that they should focus on? What do your forecast as hot topic areas to start researching now?

A: They are:

  1. Open Source, Open Source, Open Source. If you are a developer, and you really want to carve out a name for yourself, then take a long look at Open Source. Anyone can start an Open Source project. If your project is both innovative and well-crafted, you could suddenly find yourself on top of the industry. That's what happened to Linus Torvalds. With Open Source, it can happen to anyone with the right amount of imagination, development skills, and advocacy skills.
  2. Look for a niche in .NET. Microsoft is betting the company on .NET. It's a massive effort, very unlike anything the industry has ever seen (IMHO). Because it's so large, there are a lot of technological niches to specialize in. That's why I wrote my book on .NET Remoting. .NET Remoting is a great move forward in distributed objects. But Microsoft doesn't hype it as much as say, ASP.NET. Why? Because .NET Remoting is a Microsoft implementation of an industry standard. ASP.NET is a Microsoft implementation of a Microsoft standard. But, in my opinion, .NET Remoting is the more powerful and flexible of the two technologies. I would be very surprised if it didn't become important in the industry. So I decided that it was important for me to get a book into that space. When you're looking for things to be an expert in, look at lesser-known .NET technologies that will probably be big, and take a chance on them.
  3. Look at non-Microsoft technologies. Yes, the industry tends to follow MS, but there are some excellent competing technologies that there's a shortage of gurus in.
  4. Don't give up on mobile computing. Hand-held and mobile computing is rather passé in the publishing industry these days. But it's still a definite growth area. There are lots of development opportunities here.
  5. Take a look at aspect oriented programming. I don't think that AOP will cause the kind of massive shift in the industry that OOP did. Nevertheless, it's an important new way of approaching development that every programmer should learn.
  6. Don't neglect design patterns. If you don't already know what design patterns are in programming, find out now. This is an area no developer should neglect. There are a lot of excellent books on the topic. Get some and read them. You'll be glad you did.
  7. Distributed objects are only getting more important. With the advent of Web Services, .NET Remoting, J2EE, and similar technologies, distributed objects are getting easier to create and more important to a company's bottom line. This is a definite growth area. However, distributed applications are still tough to implement. They're a real booger to debug. If you've got experience in parallel processing, you'll find that your skills transfer well to distributed systems.
  8. Keep an eye on games. Yes, games. The game programming industry really pushes the envelope in a lot of ways. They do more than just graphics. Game programmers develop really advanced techniques for efficient processing, network applications, and user interfaces. The most innovative user interface designs are coming from games. Game designers have to invent ways of communicating complex information sets between people and computers in ways that are simple, intuitive, and fun. Being familiar with what's going on in the game industry can give you extra techniques that most software designers ignore.
  9. Security is vital. In the post-9/11 world, security is more important in computing than ever. Every developer should become familiar with it and incorporate it into their personal “knowledge bank.”
  10. Be a language maven. C++ is the big favorite of many developers. Of course, Java has put on a great showing in recent years. C# looks like it will do the same. It's best to know them all.


Q: You have worked extensively with advanced C++ programming. What experiences and real world examples can you share with our audience? What are your top tips/code examples for C++ programming?
A: C++ is a fantastic language. I like it a lot. However, in complex systems, inheritance hierarchies can get to be a real problem fast. The problems with multiple inheritance are well known and well documented. When dealing with deep inheritance hierarchies, I don't think developers use abstract base classes enough. Used properly, they really go a long way toward solving inheritance hierarchies problems.

Another way to flatten inheritance hierarchies is to use templates rather than inheritance, or use templates with inheritance. Because templates are so flexible, they can often take the place of multiple layers of inheritance. I've found that I can flatten my inheritance hierarchies a lot by having my template classes derive from base classes that include some of the functionality that would normally go in the middle layers of the hierarchy. This also enables me to easily include functionality that is difficult to get into the template otherwise. In addition, it makes the template easier to debug. It can even make the footprint of your application smaller. Code in templates get instantiated for each instantiation of the template. Code inherited into a template only appears once in the program.


Q: You helped develop the .NET Mobile Internet Toolkit. Can you provide your experiences, practical examples and insider coverage of the ‘plumbing’ for .NET Web Services?
A: Actually, that statement needs clarification. It was written by a marketer for the cover of one of my books. While it's true as it stands, what I actually did was write the documentation in the toolkit, not the code. However, the people who write the documentation for Microsoft are required to know their technologies almost as well as the people who write the code. While there, I got to see a lot of the internals of the MIT. It's really a rather elegant implementation underneath. Because of deadline pressures, there were (in my opinion) some problems in the user interface for the VS.NET designer for the MIT. I think the developers on the project would agree. However, their software architecture is both robust and extensible. I really like it.

I can't get too specific with “insider” information due to a non-disclosure agreement I have with Microsoft. But the whole question of Web Services, ASP.NET, and .NET Remoting is an interesting one. These three technologies are changing the balance of computing, especially when combined with mobile computing.

When I started in computers, everything was mainframes. Microcomputers were brand new. The first computer I ever programmed on was the Apple II. In those days, applications centered on mainframes. The advent of the microcomputers pushed that to the desktop. Now, Web Services in general, and certain specific technologies (ASP.NET, .NET Remoting, and mobile computing) are pushing the “center” of the application back toward the server. The primary difference now is that, often, the server is no longer a mainframe. In many cases, it's a PC cluster. This is why so many people are saying that “the network is this system.”

The focus of an application's functionality now is in its middleware. Its center lies somewhere between the end user device (whether that's a desktop PC or a mobile phone) and the server. Middleware is what .NET is all about. It's Microsoft's attempt to tie servers running Microsoft server technologies (SQL Server, server-side user interface controls, and so on) to pervasive computing devices running Microsoft software (Windows, Windows CE, Pocket IE, etc.).


Q: You have recently written a book on Remoting with C# and .NET. What examples or scenarios can you provide from your rich store of knowledge in this area? How can COM/COM+ developers make the jump to Remoting, the new Microsoft technology for creating and accessing remote objects on an intranet or over the Internet?
A: There's two important points to make here. First, although I don't think Microsoft has said so publicly, COM/COM+ is dead. I know a fair number of people won't like me saying that. Nevertheless, it is true. To the best of my knowledge, Microsoft has no long-term plans to support COM/COM+. They'll be phasing it out. I don't think I'm revealing any big secrets there. Everyone knows that MS is betting the company on .NET. This means that COM/COM+ developers must start to make the jump to .NET as soon as possible.

Secondly, I strongly advise developers on existing systems to plan a staged move to .NET. Because of its design, .NET can be used in conjunction with existing COM/COM+ components. Basically, the COM/COM+ components that communicate with .NET objects can be put into wrappers that makes them look like .NET components. You can also create COM/COM+ wrappers for .NET components.

A staged approach means that you can build remote objects with .NET Remoting and have them talk to COM/COM+ objects. In fact, the COM/COM+ objects that you're replacing can be used at the same time as the .NET Remoting objects. So if there's a serious development error in the .NET Remoting objects, you can still keep your existing COM/COM+ components online. You application continues to run normally during deployment. Once you've determined that the objects built with .NET Remoting work properly, you can remove the COM/COM+ objects.

The sheer magnitude of new .NET technologies can mean major renovations to a company's system. A staged deployment helps make the move much less painful and decreases the potential for serious errors. Each new component or technology can be incorporated into the system one by one, giving you time to do the integration testing that ensures your application is robust.

If you're going .NET for new systems, I strongly recommend you build them completely from managed .NET code. The biggest security hole in .NET is its interface to unmanaged code. COM/COM+ components comprise the biggest chunk of unmanaged code in almost every application.

If you do use unmanaged code, be careful. Yes, Visual Studio can automatically generate nice wrappers so you can use COM/COM+ components with .NET components. But do the wrappers provide the security you need? Maybe. Or maybe not. Either way, COM/COM+ components should be seen as less trusted than .NET components, both in terms of reliability and security. If you build your system with this mindset, it's much less likely to be compromised by a malfunctioning or malicious COM/COM+ component.


Q: You have authored books and written documentation for technologies? Please share your experiences from doing this work. What ten tips and examples can you provide to others who wish to work in this area? What stories can you share from your work in this area?
A: Most early software manuals were written by the developers who wrote the program. They were garbage. Programmers who can write documentation worth reading are not very common. If you're a programmer that can write, you can do developer documentation and probably make more money than you can as a programmer. However, you'll be working on contract a lot, with all that implies. There are good full-time opportunities for programmer/writers. But you probably won't be able to write books on the side if you're a full time employee of some company. So you have to choose.

It takes years to get to the point where you can make a living writing books. You have to write a few while you're working another job. Either that, or save up a lot of money before you quit. You need at least a year's salary saved up, and I'd recommend two. It takes that long before you get a decent revenue stream built up from your books. Carving out a niche for yourself writing books takes careful planning and time.

Before anyone will look at you for a book, you've got to have some writing credits. Start by writing articles for developer magazines and local computer publications. After you've been published a few times, you can try to get a book contract.

Whatever you do, don't do what I did. Don't go it alone. I got several contracts right away, which was good. But I didn't negotiate well, so I didn't make much money on my first few books. If you've got an idea for a book, put together an outline and a proposal. Then find an agent. Here's a bit of a promotion, but my agency is Studio B (www.studiob.com). I don't hesitate to recommend them.

Your agent looks over the proposal, and will probably help you develop it into a format that publishers like it to be in. Next, he or she submits the proposal to the publishers that he or she thinks will most likely publish it. If it's a good proposal, you'll get a contract. Then you write.

If you've got some writing credits on your resume, but haven't done a book, you may want to consider coauthoring with an established writer. Established writers can walk you through the process of getting published and handle the production issues that writers have to deal with. This lets you focus on the writing process and get that down before you have to deal with other issues related to producing a book. It's a common experience for writers to not make any money on their first book. Teaming with an experienced writer can help avoid that.

I'm always on the lookout for reliable, knowledgeable programmers who can write well. In fact, I'll be teaming up on a book with a brilliant astronomer/software engineer/writer. He's someone I think will do well writing books. Brilliant guy. But he's never done a book before. It's good for me because, with his help, I can take on larger projects or get projects done faster. It helps him because I can show him how to organize a book and teach him pedagogy that works.

One tip I would give all aspiring writers. Look at other people's books. If you like a book, ask yourself why. What elements of the writer's style work well for you? What pedagogical elements seem particularly effective? Basically, what makes the book good? When you figure it out, copy those elements shamelessly. As an author of computer books, you're really a teacher. There's nothing wrong with copying good teaching style. Just don't copy content. That's plagiarism.


Q: You are an international and well respected authority on C# development and its pitfalls and shortcomings. With your extensive experience, you have developed solutions and techniques for improving performance. What are your top specific solutions for major C# programming problems?
A: C# is not now, nor do I think it ever will be, the high performance language that C++ is. But that's ok. It's not intended for those types of applications. It is a direct competitor to Java, and it has many of Java's same strengths and weaknesses.

Some of C#'s bottlenecks are also the same as those of C++. For example, deep inheritance hierarchies can be a real slowdown. Using interfaces and abstract base classes can really help.

Also, like C++ and Java, throwing exceptions in C# can cause some real performance problems. Exceptions should only be thrown in exceptional circumstances.

Some of C#'s best features are the ones that cause the biggest performance bottlenecks. Take reflection, for example. Very cool feature. But using it to determine the type of an object, and then dynamically create and use the object at runtime is slow. Think carefully before you use it. Make sure your implementation really requires it.


Q: Your books are highly recommended. What led you to write these masterful works?
A: Thanks for those kind words. I wrote my textbooks because, when I was teaching, I couldn't find any textbooks with a good mix of theory, hands-on application, and real world experience. Most books either focus on theory or application, but don't present a balanced view of both.

Books like The Complete Idiot's Guide to C# Programming and Remoting with C# and .NET were projects suggested to me by publishers that I thought would be fun. And they were. They both were in areas that I have strong experience in, so that helped.

As a writer, I really enjoy what I do. There's a certain level of what I call “overhead work” that you have to do when you write for a living. Mainly stuff like writing proposals and so forth. That's not bad, but I'm always in a hurry to get through it so I can start researching and writing. That's the fun part of the job.


Q: Describe future book titles and articles can we expect from you?
A: I've got some projects related to game programming that look likely. Also, because DirectX is going .NET, I'll probably be working in that area. In addition to some projects related to Open Source, I'm developing some book ideas focused on C#.


Q: Can you describe some of the projects that you have worked on and what tips you can pass on?
A: I've found that the success of failure of projects almost never is determined by technological factors. Almost without exception, it's something else. Usually, that something else is poor management.

For example, I once worked on a very pioneering game. It was intended to be an interactive movie aimed at girls. We used digitized video in which the actors talked to the camera like they were talking to a person. When you played it back on a PC, they looked like they were talking to you. The player could make choices, which caused the video to branch. The story being told had many different endings, depending on what the player chose along the way.

Disaster set in when the president and CEO of the company assigned his wife to the project. Originally, I was running it. By about halfway through the development cycle, everyone was suddenly calling her the “Executive Producer” and me the “Technical Producer.” You see the difference.

Unfortunately, the “Executive Producer” had never run a project of any kind. The result was chaos. Eventually, the game was released. It contained 7 CDs of video. To my knowledge, it was the largest game ever released. But it became clear that they project would bite the dust about 3/4 of the way through. We started hemorrhaging people - all of the best people - in a big way. Before the game was released, I left to go write software for Microsoft's Interactive TV effort (which they later canceled, bummer).

The game, although notable, was a failure. But it wasn't for technical reasons. I wrote the proof of concept demo early in the project. Technically, we knew exactly where we were going. We had great writers and actors. The writers accomplished miracles, in my opinion. The game was a failure for no other reason than it had a terrible management situation. In fact, the game was such a spectacular failure that it made the company go out of business.

The point here is that I learned the hard way that you have to really be aware of your employment situation. As developers, we tend to focus on the fun of making new technology. Forgetting to watch out for your career can put you into bad situations. It's important to have good managers and pick your projects carefully.


Q: Please provide your views on UML, and XML?
A: Simply put, UML is vital for every software engineer to know. You can't get by without it. XML is rapidly becoming just as necessary. At the very least, XML will be the standard for exchanging data between distributed objects and programs for the foreseeable future.


Q: What are the hottest topics that all IT professionals must know to be successful in the short term and long term?
A: Without a doubt, middleware, .NET, and security. Without a solid knowledge of these topics, you're not going to make it in today's IT environment.


Q: What would be your recommended top ten references for the serious developer?
A: Anything written by me. Ok, the serious answer is, it can depend on what language you're developing in. But I'm going to assume that most people want to be as versatile as possible, so they're learning C, C++, C# and Java. Here's my recommendations (with a little shameless self-promotion).

For those new to C#, here's my book on the subject:

  • The Complete Idiot's Guide to C# Programming David Conger
  • C# For Experienced ProgrammersHarvey M. Deitel Paul J. Deitel Tem R. Nieto Marina Zlatkina Jeffrey A. Listfield Cheryl H. Yaeger
  • Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma Ralph Johnson Designed by Grady Booch
  • AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis William J. Brown, Raphael C. Malveau, Hays W. "Skip" McCormick III and Thomas J. Mowbray
  • The Art of Computer Programming Volumes 1-3 Donald E. Knuth
  • The C++ Programming Language Bjarne Stroustrup
  • Effective C++ : 50 Specific Ways to Improve Your Programs and Design Scott Meyers
  • More Effective C++ Scott Meyers
  • Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library Scott Meyers
  • Inroads to Software Quality Alka Jarvis, Vern Crandall
  • Software Implementation Michael Marcotty
  • Software Optimization for High Performance Computing Kevin R. Wadleigh, Isom, L. Crawford

C is not dead yet. People are still learning and using it. Here's my book on the subject.

  • Software Development in C: A Practical Approach to Programming and DesignDavid Conger
  • The Waite Group's C Primer Plus Stephen Prata
  • Java How to Program 4TH Harvey M. Deitel Paul J. Deitel

OK, so this is more than 10, but who's counting?


Q: You have done extensive research in a number of high-tech areas. Can you describe the results of your research and tips you can pass onto the audience?
A: I used to do a lot of work in parallel processing systems for military applications. Parallel processing PCs are becoming more and more affordable. Increasingly, parallel processing and multithreading will become common in programming. These two topics do not receive enough attention from most programmers. Many types of programs could achieve better performance by using one or both of these techniques.


Q: David, can you expand on how .NET is so different: a new way to build distributed desktop applications; a new way to produce mobile applications; very different from classic COM (no class factory, doesn’t use IUknown, no registration in the registry)?
A: I can't really say enough about how much easier and better .NET is when compared to classic COM. To be honest, I've always hated COM. And I mean always. I thought it was a crippled solution from the first time I saw it. The Win32 API and the Windows registry have also long been favorite targets of my criticisms. .NET gets rid of it all. You don't have to deal with the Win32 API, you don't have to worry about putting object GUIDs in the registry, As you mentioned, there's none of that silly IUnknown crap to worry about. No reference counting, and so on, and so on. It's so much easier to get a distributed system up and running quickly.

In addition, distributed apps under .NET are much more customizable. The .NET Remoting architecture is very extensible. You can write your own channel sinks, enhance the proxy, and much, much more. All of this involves a lot of digging into the guts of .NET in general and .NET Remoting in particular. That's not easy, especially because the Microsoft documentation for .NET is not always correct (at least, it isn't in the current release). When something complex should work and it doesn't, you've got to consider the possibility that the system does not work like the documentation says it does.


Q: Where do you see C# positioned and where do you see it evolving over the next five years?
A: C# will challenge Java and VB. I think a fair number of VB programmers will shift to C#. Java, on the other hand, will always have a loyal following.


Q: What are your tips for learning the types defined in the .NET base class libraries since this is the heart of .NET and not necessarily learning the syntax of C# or other supported languages?
A: Just tinker with it. Use Visual Studio's object browser a lot. Learn to use Microsoft's documentation. There's something of an art to it. You have to be willing to learn related concepts. For example, if you haven't had a lot of experience with .NET, the underlying architecture of .NET Remoting can seem very confusing until you understand the underpinnings of .NET itself. In most cases, how things are done in the guts of .NET Remoting is just an extension of how things are done in the guts of .NET.


Q: Can you comment on the integration of mainframe, Unix, and Windows-based technologies and how they all fit in large, complex, enterprise environments?
A: They fit badly right now. Vendors need to be more willing to agree to standards. The advent of XML, SOAP, and so on are helping in a BIG way. But down in the trenches, sysops, developers, and testers are struggling unnecessarily due to the failure of vendors to consider integration issues with their competitor's products. From their point of view, I can see why they don't spend as much effort on it as they should. Nevertheless, their customers would be a lot happier if they made a better effort to make their software “play nice” with other products.


Q: What changes do you see for the future of computing, conducting business, and the use of the Internet?
A: The situation is so open to major change right now that I wouldn't even try to make a prediction.


Q: What would you do different if you started again, having gone through this authoring experience over the years?
A: I'd get an agent right away. I'd have collaborated with experienced authors on a couple of books. I'd have started with smaller projects that I could get out quickly and that had a larger market. I started with textbooks while working a full time job. Each book took me about a year to write. As you might expect, some made money, some didn't. So an entire year might go by with no real advancement in my writing career. Doing smaller projects at first gives you more books to potentially get income from. Books like that tend to die out quickly. But they give you a revenue stream to work from. The larger projects stay on the market longer. You should shift toward them as you get more established.


Q: If you were doing this interview, what five questions would you ask of someone in your position and what would be your answers?
A: If I were doing this interview, I might ask what the main advantages are of being a writer (and teacher) rather than a developer. As I see it, the main advantage is that I get to have a life as a writer. I live way out in the sticks. No DSL is available. Cable modem Internet access just came this year. Not far from where I live (western Washington state), millions of people flood the highways every day in a commute that often lasts 2 hours. That is, it lasts 2 hours unless it rains, which seems to cause everyone to forget how to drive. In that case, it can take 8 hours to get from Microsoft to my house. It's happened to me before.

As a writer, I can live where I want and not have to commute. If I want to teach as well, I can get a job at most community colleges or universities. So there are really not many limits on where I can live.

All this sounds good, but it takes years to get to. Fighting your way out of the rat race is a long, hard struggle. But it can be done.


Q: It’s a blank slate, what added comments would you like to give to enterprise corporations and organizations?
A: Consider Open Source. Starting an Open Source project to produce software for your industry can make you the company or organization that sets the standards. Anyone can see what that's done for Microsoft. You can have an influence in your industry that is larger than your company could have any other way by creating and giving away the software that your entire industry uses.


Q: Thank you for sharing your valuable insights with us today and we look forward to reading your books, and articles.
A: It was a pleasure. That's for the opportunity.

 

 

 

Copyright © 2000 - 2002 Canadian Information Processing Society All rights reserved.