eRUNWAY Work Experience

I worked at eRUNWAY from April 2001 to May 2002 as an Architect. While I was there, it changed its name to Virtusa.

eRUNWAY is a consulting company based in Westborough, MA, that does software and application development for its clients using development centers in Sri Lanka and India. As an architect, my responsibilities included sales support, project requirements capture, overall design, monitoring the development being done by the off-shore development team, handling technical issues with the client, etc. Development is not supposed to be done in U.S., because the cost is higher; however, I ended up doing a fair amount, mostly because I preferred to do myself at least the skeleton of sections of the system that were particularly crucial or challenging.

Most of my time at eRUNWAY was spent with Vignette, a client based in Austin, TX. This project involved Java development, Swing, applets, JSP, JavaScript, servlets, Struts, Weblogic EJB server, and SOAP.

The SOAP work was particularly interesting. Frustrated by the complexity of the Apache SOAP implementation, I developed a simple but conformant SOAP implementation that used recursive traversal to transfer the following object-types:

• Primitive types (int, float, etc.)
• Wrapped primitive types (Integer, Float, etc.)
• Vectors and Hashtables
• Multi-dimensional arrays
• Arbitrary Java objects conforming to the Javabean get/set pattern
• Arbitrary Java objects for which a BeanInfo was provided

The composite objects were handled if all their elements could be handled. Thus, objects of arbitrary complexity could be disassembled and reassembled. Java reflection and dynamic proxies were used to transfer the call.

In addition, the Apache SOAP implementation, while wondrously standards-conformant, does not pay sufficient attention to real-world issues, as follows:

Apache SOAP directly creates a socket connection and talks the HTTP protocol. Usually, this would be fine, but if the request is coming from an applet running in a browser, then it would be more useful if the request should appear to be like any other request originating from the browser, because then the server could associate it with the user's session, etc. My implemention, by contrast, used the class URLConnection. I empirically determined that Internet Explorer's implementation of this class creates HTTP connections that inherit the browser's context, including cookies that carry the session.

Typically, the client-side SOAP caller passes the requisite number of arguments declared by the SOAP method, and the server-side SOAP implementation calls an implementation of a stub method that takes that number of arguments. However, using SOAP would be easier if the server-side could pass additional data to the server-side implementation (such as the user's session), beyond those declared in the stub. Apache SOAP did not provide this facility. My design, by contrast, permitted it as follows:

• The server-side implementation had to supply a class that implemented the methods being called. In addition, the class was permitted to have constructors that took arguments.
• Each HTTP request was handled by a fragmentary servlet or JSP that would invoke the SOAP implementation, passing along any desired additional arguments (such as the session). The SOAP implementation would use these arguments to construct a new instance of the correct server-side implementation class. Thus the desired additional arguments would be available to the method as member arguments of that class instance, while the caller-supplied arguments are passed as method arguments.

A typical client call would look like this:

clientSideSOAPHandle.someMethod(arg1, arg2, arg3);

The server-side would supply an interface that declared that method:

public interface MyInterface {
  public int someMethod(int arg1, String arg2, Person arg3);
}

The server-side implementation class would look like this:

public class MyImpl implements MyInterface {
  HttpSession session;
  public MyImpl(HttpSession session) { this.session = session; }
  public int someMethod(int arg1, String arg2, Person arg3) {
    ...
  }
}

The servlet would call the SOAP implementation with the following information:

• The name of the interface (MyInterface). This would be mapped to the implementation class.
• The name of the desired method (someMethod).
• The arguments to pass to the constructor (just the single HttpSession argument, in this case).
• The arguments to pass to the method (arg1, arg2, arg3).

This allowed the called method to do its work while having access to the context in which it was called, such as the HttpSession (or some such convenient object capturing the context), while at the same time not needing to have anything Web-specific in the SOAP implementation. This proved to be a very fruitful framework in which the developers could do their application-level coding.

Thus I quickly designed and developed the conformant SOAP implementation, making sure that it met the developers' requirements, rather than focusing on esoteric XML features of incidental value.

In addition, I got very good experience managing large teams with developers of varying skills, and also managing such teams remotely. I did not find it a productive environment in which to work. The hope is that over sixteen hours of work can be done on the project every calendar day, eight hours in U.S., eight hours in Sri Lanka (or India). What happened in practice is more like this:

Date (U.S. time)	Me	Sri Lanka
Monday afternoon	Please look at issue X.
Monday night		Here's details on issue X.
Tuesday noon	No, that's not issue X, issue X is this. Please look at it.
Tuesday night		Do you mean Y? Here's how X compares with Y.
Wednesday noon	No, X and Y are not the same, this is what I mean by X.

The net result is that some issue that could be sorted out in half an hour if all parties were gathered in front of a white-board ends up taking three days, or longer, to resolve. That's a far cry from the promised "sixteen hours of work per day." What would happen in practice is that the remote team would adjust their working hours to overlap more with the U.S. team's hours. They would routinely work from noon to midnight. At 1pm in the U.S. (Eastern Standard Time), we'd be surprised to keep getting emails from the Sri Lankan team, where the time would be nearly midnight.

I believe remote (offshore) development works well in cases where there's little communication needed between the local and remote teams. That can certainly be the case for QA tasks, and maybe for the development of software that can be very well specified. However, such software projects are fairly rare. My belief is that, in most cases, companies embrace such remote teams simply because the cost saving is easily quantifiable, whereas the impact on aspects such as software quality, end-user satisfaction, etc., cannot be easily measured or predicted.

During the tech slowdown in 2002, Virtusa reduced the salaries of its US-based staff, stating that the reduced salaries reflect "market rates". I accepted the implicit challenge and found a job with a higher salary! Anyway, it didn't really make sense for a company like Virtusa, that does offshore development, to have expensive US staff.