Adam Borbidge

Co-op experience, LMGT

August 7, 2001

During the summer of 1999, spring Y2K, and fall ’00, I worked as a co-op for COMSAT Laboratories**, a division of COMSAT Corporation, a global leader in the satellite communications industry. The following is a description of my personal experience in Clarksburg as well as a summary of pertinent changes in policy made at the Labs, and its parent company, Comsat International.

Historically, Comsat Laboratories served as the research center for the corporation, headquartered in Bethesda. The site in Clarksburg was designed to accommodate the construction of satellites. The hallway down the center is wide enough for a satellite to be moved from one workshop to the next. The building is a quarter mile in length. Nowadays, the hardware is much smaller. Linkway 2000 terminals are the size of PCs. One of the rack sets for TCMS is the size of a dresser. Increasingly, the Labs’ generates more profit from software and smaller hardware.

During my first rotation, everyone prepared for and succeeded in our first ISO 9000 audit. Comsat was in merger negotiations with Lockheed Martin when I returned for my second rotation in the first January of the new millennium. During this time, Comsat lobbied for Congressional legislation that would privatize the satellite industry. When returning for my final rotation in late August of the same year, I saw new logos on stationary and reported to the security office in Clarksburg for my Lockheed Martin Global Telecommunications (LMGT) identification card. In September 2001, I will make the journey down 270 South and take the Clarksburg exit more time to start my permanent position as an Associate Software Engineer for LMGT.

The last couple years have been dynamic for Comsat Laboratories, a research lab built on farmland, where the security supervisor still takes cares of some ducks and geese in a pond sitting on the property in the shadow of trees and some enormous satellite dishes. The internal transitions for the Network Planning & Management Development department at Comsat Laboratories reflect strategic decisions by board members as well as an increase in the number of contracts awarded to my company. As former Labs President Ben Pontano said, we were "structured for growth." In retrospect, my transition from student to co-op to programmer and presently to associate software engineer has been almost as dramatic.

There are several organizations within Comsat Laboratories and several departments within each organization. This is the administrative hierarchy of the company. I spent my time working for Network Planning and Management Development. Shortly before my arrival, it was called Software Development Department. Then it became Software Development Organization. It changed names again to become NPMD. Other organizations include Human Resources, Legal, Government Contracts, Accounting, and Products Development. Within NPMD, there are two groups: Software and Communication Systems Engineering and Software and Computer Technologies. My manager, Gary Moxley, held two positions simultaneously in NPMD: Principal Software Scientist and Network Architecture and Solutions Department Manager (in the Communications Systems Engineering group). In my twelve months at the Labs, I worked on two projects: NTI (specifically the TCMS component) and SSDM. I spent the first two rotations on the former, under the immediate supervision of Manan Thakkar, Staff Software Scientist, in the Network Management Systems department. In my final rotation I did work on SSDM for Deb Diefes, Software Products Manager. My advisor in this endeavor was Sujatha Chandramowleeswaran, Software Engineer in the Database Technology Department of the Software and Computer Technologies group.

My point in blitzing the reader with so many names and acronyms is to convey the rate and magnitude of change within Comsat Laboratories. The departments and groups just mentioned are the result of an administrative reorganization of the Labs’ talent to better suit the case load won by the deal makers at my company. Periodically, I attended "All Hands" meetings for the department. These meetings kept employees updated on the growth of the organization. New employees, contracts, and promotions were recognized. In addition, these meetings were a chance to address issues such as changes in benefits and upcoming audits. These meetings were well-attended in my second and third rotations when policies for LMGT and "Comsat Heritage" employees were being normalized and the possibilities of an IPO were imminent.

Project teams held their own meetings. The focus was different for group meetings. Teams were composed of a few members from each department (e.g. Database, GUI, Network Architecture). Team meetings addressed changes in project requirements, progress toward milestones, and coding conventions (not to be underestimated). One other kind of meeting we attended were code reviews, to check the work done by a team or individual on a unit of the project. At these meetings, pages were checked primarily for conformance to the coding standards, readability, and errors in logic. On a day-to-day basis I worked more closely with project team members than with staff from my department, although the latter were always helpful with technical questions.

The first lesson I learned at Comsat Laboratories was that computer scientists in the "real world" still do research. I spent the first week there researching and trying small prototype programs. My primary resources were a book, entitled Unix Network Programming, and some proprietary libraries created by software engineers in the organization for a prior project. After the first week, I joined the NTI project. Over the course of the semester, I was stumped several times on various problems. My immediate superior and mentor, Manan Thakkar was quick to offer me a simple fix or sit down and debug my code quickly rather than have me spend hours by myself. In short, "research" at the Labs was cooperative effort with an immediate practical application.

Part of my research was writing some small prototypes that would run simple client and servers. Initially, these were written in C, then in C++ using some of the wrapper classes in our libraries. (My mentor especially was very keen on code reuse to save time.) Six weeks into this rotation I also began studying and experimenting with a COTS package known as ISM from Groupe Bull. One of the components of this package was SMB. To work with SMB, I had to learn SML, a LISP-style programming language. There was also an API, written in C, for SMB. Toward the end of the term, I was experimenting with some Open Source libraries called ACE. In each case, I prepared documented prototypes for full-time employees to use when they needed to implement their designs when I returned to school.

In the early stages, both of NTI and my work rotation, I documented my code only to the extent that it would make sense to me when I went back to it later on. As the project evolved, coding standards, documentation, and version control became more important as collaboration increased. I gained some experience writing internal and external documentation. For those that are not aware, internal documentation refers to the comments within the code (e.g. semantic descriptions in English, indentation, function headers, file headers, etc.) External documentation could be small tutorials for our work, coding standards, or practical guides to using the new software tools. I wrote an informal beginner’s guide to RCS that could be referenced by all NTI project members via the Developer’s Handbook, a resource available electronically via public directory. Periodically, libraries and object files would be updated to reflect the latest build. RCS helped developers to track revisions and was especially helpful when multiple parties worked on the same file. My mentor and I shared to-do lists to check off little milestones in our work.

The tools and software I used fit into various categories of software development. I worked in UNIX and Windows environments. For the small prototypes, Emacs and gcc were sufficient to edit, compile, and execute my work. To create class and library diagrams I used Visio for Windows. Because I was new to UNIX, I learned a lot about this system too.

As the complexity of the code increased and the project progressed, my code had to measure up to higher standards. This is when I was instructed in the use of RCS for version control, Xdb for debugging, and Makefiles for compiling, linking, and building. I began reading the Visio diagrams Manan designed when it came time to build utility, data handling, and connection libraries. When these libraries were tested it was time to bring them out of the "sandbox" (private workspace) and into the public directories so other developers could use them.

After a month on the job, I attended a session of the much talked about Preliminary Design Review (PDR) with NTI’s client, INTELSAT. Binders full of specifications and actions items were reviewed over the course of a week. At this level of discourse I did not see a single line of code. There were only questions of logic and semantics.

Thus far, I haven’t done anything other than talk shop. In the very beginning, I alluded to the duck pond. This was only one of the many attractions on or near Comsat property. A quarter mile down the road is Black Hills Regional Park, a wonderful place where we had picnics and volleyball games. It is also a favorite location for runners like myself. Just before the exit onto the road to this park was our softball field, across the main access road from some of our largest earth stations. Every Friday, my supervisor Gary consistently outmaneuvered and outstrategized his employees – in our weekly games of two-hand touch football. Every Friday afternoon before lunch a group of co-ops and regular employees would meet in the fitness center and go out to the "front lawn." Other days, employees hosted lunchtime seminars. These seminars were either practical or academic lectures on satellite technologies, career development, new programming practices, and new features of the young suite of applications Comsat has been developing for commercial sales.

I returned to the Labs in January following the Y2K apocalypse when the NTI project was in the detailed design phase. When Manan gave me a brief reintroduction to the state of affairs, I found three or four libraries in their infancy. There was a library with functions to hide the ACE function calls from the user. The rationale was to limit the number of new languages and function names the application programmers using our libraries needed to learn. The number of functions needed from ACE was a subset of its full utility, so the "wrapper" library had simplified function calls (because some of the ACE functions’ parameters were preset). Another library was solely to provide debugging and trace information of the processes we would create (e.g. message handlers, senders, receivers, and connection managers). (Must explain TCMS) The Process Management team’s primary purpose was to get processes to talk to one another. To do that they needed interfaces and some way to send data to one another. How do they do that? IPCs. A third library consisted of several dozen Interprocess Communications. Because of several different processes running in the TCMS, Steve Nash, a fellow co-op, along with myself, had to create classes for several dozen IPCs referring to a data dictionary for class attributes. Fortunately, Steve created a Perl script that could generate template source and header files. These templates could then be customized with the specific attributes and function implementations. Mechanizing this process was a real time saver and guaranteed conformity across the IPCs.

My final term at LMGT as a co-op was this past fall. SSDM, my new assignment was a 180 degree change of direction from my prior experience on NTI. Previously, I worked with a group of several other co-ops and engineers. SSDM was an individual effort with mentoring from a database engineer with experience on the project. The type of programming differed on this new project too. My part of NTI was in C and SML. I worked in a UNIX environment. Processes did not need to output to the user in order to communicate messages internal to the system. On the other end of the spectrum, SSDM is a tool for satellite operators to manage the information about the equipment they use (e.g. satellites, earth stations, remote terminals). SSDM has a GUI to display the satellite database. PowerBuilder was the primary tool I used to work on SSDM. Instead of creating a new system from designs, I referred to a list of Problem Reports, to fix bugs and make upgrades the application. I made some changes to make the application easier. Other fixes were genuine errors in the information retrieved. The version control software was a Windows package. And since this was a product and not a project for a specific client, my work was maintenance, not design or implementation. Over the course of the semester, I claimed credit for two new version numbers.

To make a real contribution to this project I had to become familiar with the use of SSDM, PowerBuilder, and some database tools. I also had to learn to write PowerScript and SQL. Once I was familiar with SSDM, I applied the lessons learned from the large team-oriented project to my new individual assignment wherever possible. The most significant carry over from NTI was a coding standards document, for myself and future SSDMers. NTI had to meet higher standards than SSDM did originally, and the disparities in coding styles for the original SSDM developers grated on my nerves after becoming so accustomed to the strictness of NTI. I didn’t find the rules of the latter stifling. I found them encouraging. In my opinion, there was less ambiguity to worry about and more freedom to creatively implement the components.

Summer ’00 was the academic semester following my second co-op rotation. I enrolled in the Operating Systems class. That summer I became a serious comparativist. The projects for the Operating Systems was extremely time consuming, and without all my work experience in UNIX, I would have been dead in the water. The first comparison I made was between the project work (NTI) and project work in class. On NTI, individual coding was supplemented by group consensus on coding standards and mutual support with debugging and code reviews. In class, individual work was not encouraged, but mandated. Add to this absolute independence the disparity between the academic and practical aspects of the class and I found myself spending as many hours on homework that semester as I did in the office in the preceding work rotation. Furthermore, I became accustomed to professional guidelines for projects. At work, I had descriptions of what objects and functions should do, as well as how they should be written for easier readability and acceptable performance. Lacking these constraints in academia, I found myself pondering ambiguities in assignments and losing track of the lines of code in my programs. The distinction between professional group work and independent academics is not correct. More accurately, I could say that the difference is between solo work and group work in general. I say this because there was a marked difference, in my opinion, in my own productivity on NTI versus SSDM. I believe I was able to bring more order to SSDM after working on NTI, but it took a long while to achieve the level of confidence where I could say, "This is the right coding standard for this project and this is why."

Besides favoring teamwork, I also developed a taste for reusable code. From the start, Manan advocated code reuse wherever possible. That sounds simple enough, but I was only able to appreciate when I worked on those big projects at the Labs. The ACE libraries and Steve Nash’s IPC generator were the two key examples that stick out in my mind.

Interprocess communications, child processes, and sockets all came up in my Operating Systems class. When I found out, I was overjoyed as only a nerd can be. The constructs of the in-class IPCs were not as complex and a couple layers closer to the system level, but I ate the stuff up, nonetheless. I was disappointed when we didn’t get to design a whole system of IPCs, but studying some other OS concepts that I recognized provided some consolation.

Besides learning better programming tactics, I became interested in project design too. As a co-op, I was excused from the ISO training required for permanent employees, but from what I had been told, the ISO certification added a certain amount of credibility to the company. In the developers’ view, the next step was achieving SEI CMM Level III certification. Briefly, this meant that our organization’s software development process was managed to some extent, thus reducing the probability of errors in our work. Both ISO and SEI CMM were organizational certifications. Two personal certifications that are foremost in my mind are Sun’s Java Developer Certification and the Personal Software Process administered by the SEI. Were it not for my time at Comsat, I would not have been privy to these accreditations for professional development. Some informal courses are available at Comsat. Furthermore, I was able to return to Pitt to participate in the Java Programming course provided by the CSSD. I also took Dr. Chang’s Multimedia Software Engineering course that provided further insight into other SEI initiatives.

INTELSAT – International Satellite Organization

CSSD – Computing Systems and Services Development

COTS – Commercial-Off-The-Shelf

SSDM – Satellite System Data Manager

TCMS – TDMA Central Management System

TDMA – Time Division Multiple Access

ACE – Adaptive Communications Environment

CMM – Capability Maturity Model

IPC – Inter Process Communications

ISM – Integrated Service Manager

ISO – International Standards Organization

NTI – New TDMA Infrastructure

PDR – Preliminary Design Review

SEI – Software Engineering Institute

SMB – System Messages Bus

SML – System Markup Language