DevSource: You used to live in the U.S., but emigrated to Israel several years ago. I know that it's easy for North American developers (or people in general) to assume that what we have here is representative of the rest of the world. What's different about software development in other countries?

In some ways, I am not the best person to answer this question. The Israel software industry is rather similar to the US software industry, and American culture. More importantly, the talent and technological infrastructure (e.g. phone systems, computer hardware, and high-speed Internet access) available here is on par with that in the US. That is probably why most of the leading high-tech companies have at least one development facility here — that includes Intel, Motorola, IBM, Sun, and Microsoft, to name just a few. In fact, Microsoft's Israel R&D center was the first Microsoft R&D center outside of the US.

On the other hand, there are definitely locale-specific differences. I have been a major proponent of Visual Basic since VB3 (1993). At that time, I was considered pretty crazy in Israel. Although in the US the ratio of VB to C++ developers was around 80:20, here in Israel it was probably the exact opposite. I attribute that to the fact that the Israeli software industry at the time was heavily rooted in and based on the electronics and defense industries, which of course are heavily C++ oriented.

On the other hand, Israel doesn't have the size or quantity of mid-sized and large corporations as does the US, where VB was used extensively for in-house development. These two local factors are what made the VB-C++ landscape so much different here than in the US. Since then, we have fallen more in line with the numbers in the US, although we probably still have a higher ratio of C++ (or C#) developers.

DevSource: What have you learned about ways teams can work effectively across huge distances?

I have worked remotely on many projects of different types and sizes, both as a team member and as a independent supplier. The essential, and probably obvious, key to the success of such projects is communication. Communication is important even when you are working in the same cubicle as other team members, but becomes even more critical when the distances are greater and when you are an "outsider."

First of all, you must keep team members and/or clients up to date on what is happening, including problems and concerns. You should also be constantly interacting with them to make sure you correctly understand their requirements and don't end up with a great implementation of the wrong things. You also need to use a variety of media and select the right medium at the right time. I typically prefer to start with a document and/or e-mail, to get up to speed and absorb/analyze the subject at hand. Putting things in writing is a very useful process—whether I am the writer or the reader—since it forces you to think, organize, and express your ideas. After that, I will normally want to have a more interactive discussion, so I will pick up the phone or arrange a time for conference call.

I also believe that even with all the e-mail, blogs, Instant Messages, phone calls, and even video conferences that you may have, there is no substitute for "live," face to face interaction. This is the best and deepest way of establishing and maintaining relationships — which is the key to success of projects, not to mention businesses. When my company is developing software at our site, it doesn't matter if the client is across town or across the globe, I will always make sure to have periodic face to face meetings, in addition to all of the other modes of communication.

We are currently working on a Visual Studio 2005 enterprise application for a client in New York City. We use the combination of written documents, email, and phone calls on an ongoing basis. I even have a 4-server network in our office with the same software configuration as they have at their site, and we have a dedicated line from that network to their office network, in case we need to jointly debug some problems. But we supplement this with regular face to face meetings; sometimes they'll come here and sometimes we'll go there.

DevSource: You've been a computer consultant for a very long time. What advice can you offer to developers who are thinking of hanging up their own shingle?

There are lots of good books and articles out there that offer plenty of good advice. They are definitely worth reading, but are often too generic in order to reach a larger audience. One of the most useful things I have done was to hang out in the CONSULT forum on Compuserve about 15 years, where I had the opportunity to get real-world and relevant ideas and advice from people (like you!) doing things similar to what I thought I might be doing in the future. I also opted for some more structured and formal education and completed a Masters in Management degree.

But let me try to offer some of advice of my own. I think that it is very important to specialize, or at least to clearly delineate and express your area of expertise. It could be that you are a "jack of all trades" generalist, a vertical industry specialist, or a guru in a particular technology or toolset. But it should be clear to you and your potential clients what your expertise is. In my case, I have consciously chosen not to specialize in a particular domain, but rather in the Microsoft platform and tools. Even within that, I emphasize some tools/technologies more than others, such as my expertise in database access and applications. With .NET, the choice of language is far less important, but before .NET, I had decided to focus on VB. When I first started out consulting and had periods of no work, I would turn down offers of work in C/C++, even though I had down a lot of development in those languages (I spent many years developing embedded/real-time software and I learned Windows programming, like all real Windows programmers, by reading Petzold and programming in C). People thought I was crazy, but I think it was the right choice for my business model, since it was against my strategic direction. It is hard enough to keep up and maintain a reasonable level of expertise in two or three areas, along with competency in a few others. You can't reasonable claim or attempt expertise in many more.