About the Employer

For the past two summers I have been employed as a summer intern with the Advanced Operations and Technology (AOT) department within DynCorp, a privately owned multi-billion dollar company. DynCorp’s world and corporate headquarters are both located in Reston, Virginia. My specific office location was situated in the Edmund Halley Dr. location, only just down the street from the Defense Mapping Agency off of the Fairfax County Parkway.

My immediate supervisor throughout this past summer’s internship was Kip Porterfield. Kip is a fifteen-year veteran of application and database development and has only been with the AOT department for just over a year, arriving during the summer of 2001 just as I was ending my internship that summer. Kip holds a bachelor’s degree in Computer Science from Virginia Tech, as do several other members of the AOT department. He is considered a Principal Developer within the department.

Kip’s supervisor, and the original DynCorp employee who hired me for the position, is Margi Patel. Margi is the manager of the AOT department, yet she does not fit the typical role of a manager. Since so many of the projects that enter the AOT department are handled by a single developer, she tends to keep a keen eye on the progress of each project yet does not push any single developer to finish by a certain deadline.

By this time you may be wondering about the nature of the AOT department. To clear up this aspect of the internship, I offer the explanation that AOT is a “jack of all trades” department of no more than seven or eight members who handle internal corporate projects. On any given day, several members of the team will be working individually on projects ranging from a PeopleSoft portal to a prototype web application for the HR or finance departments within DynCorp. Other members of the team will be handling advanced server installation and troubleshooting and are on call 24-7 to respond to critical connectivity issues to DynCorp’s corporate web site and for applications that are accessed by DynCorp employees. Margi, as the manager, handles purchasing decisions and answers to the Vice President of DynCorp’s Information Technology department. The AOT department is as critical, if not more so, than the normal IT department within DynCorp.

The number of hours I worked each week was much higher in comparison to my prior internships. Both Margi and Kip expected nothing less than professional behavior and work ethic. However, both supervisors were always very understanding about occasional requests for vacation time, outside appointments; I also received a fair amount of attention, and the occasional prank, being the only intern in the department. Everyone in the department was always very helpful and warm, many of us would take a few minutes each day to chat. It was interesting to note how, although I was the youngest among the other members, their enthusiasm of computer games, movies, and more did not go untarnished from their college days. In addition, it was a department obsession to order takeout from Baja Fresh every Friday. Sometimes we would order from the restaurant two or three times a week. As a practical joke, one of the members created a simple ASP.NET web site to allow us to place our orders for our next “Baja Fresh day”.

About My Job

Coming from a successful summer internship with AOT in the summer of 2001, I entered this summer’s ongoing internship with the notion that I would have the chance to work in software and/or web development. On the first day of work, after rekindling my security badge and setting up my workstation, I received word that I would indeed be working on two separate projects. Each project called for development using Microsoft’s very recent .NET architecture and SQL Server 2000. Both of these technologies were knew to me at the time since I had received no formal training in database development or in any programming languages other than C/C++, Java, HTML, and ASP.

The first project called for a web application (developed in C#) to allow local DynCorp facility managers to update personnel information in regards to space allocation, office and room assignments, and so on. The task of doing so had, up to this point, been handled through an Excel spreadsheet. One look at the spreadsheet first-hand showed just how badly this application was necessary. An important side of this project, deemed the Facilities Management System, was that the application was required to be implemented using an ongoing SQL database project known as “HUGE!”. HUGE, as was called because of the sheer size and complexity of the database, started off as a centralized SQL database incorporating specific PeopleSoft information about each DynCorp employee of past and present. The AOT department took this database one step further by following up on the notion of a centralized database that could be used by all future DynCorp web applications. Thus, the database grew and grew as tables were added to include such personalized information as employee cell phone numbers, security permissions, office rooms and locations that were not free-text, but actual database objects themselves. Thus, the Facilities Management System would allow those who use it to create rooms with specific information and move personnel around within the database, rather than using an out-dated and clumsy spreadsheet.

The second project closely followed the idea of the Facilities application and indeed the two applications even cooperated together. The specifics of this application called for allowing telecommunications managers to create and edit information related to the “jack boxes” and “phone jacks” associated with each room. Through several meetings with telecommunications managers and discussion amongst our department, I deciphered the sort of functionality the managers needed to have; such as moving an employee’s telephone to another room, editing specific information about a phone jack (analog, digital, etc.), and so on.

Image: A more recent desing build of consolidated SQL database.

Not only did I work on both of these projects simultaneously, but I also helped Kip with the implementation of the “HUGE” database. At some points during my development I came to realize that certain aspects of the database’s design, which Kip was primary responsible for, would not fit the needs of the applications in a sensible way. Therefore the two of us worked together on a daily basis to build in changes to the existing database and keep track of the changes. Of course, as any software development department should follow, just making a minor change to the database required testing and more testing before the changes were propagated to the database found and accessed in the production environment. [See diagram for specific information about the HUGE database.]

At first, the development of each application came along slowly. Not only was I learning a new programming language, C#, but I was also having to learn how to use SQL and T-SQL to create views and stored procedures which would later be used in my applications. Just understanding the requirements, which were handed to me from the start but later added to and altered through my own meetings with other employees, was a task that at first seemed larger than life. It is difficult to find yourself having to understand concepts that are entirely foreign, such as telecommunications terminology and the business rules behind moving an employee from one office build to another.

As a first-time developer it was of personal importance for me to create a web application that was not only functional and bug-free, but to design a user interface that was attractive and easy to use. It was just this task that proved to very difficult; although I have created many web sites through my past personal and professional experiences, it was new for me to have to create an interface that was more “usable” than “fashionable”. Thus, the user interface for both of my applications went through several iterations before I was content and happy with its appearance and ease of use.

While I designed the user interface for my applications I also tooled with the actual class and component design of my applications. The most fascinating aspect of the Microsoft’s .NET framework is the concept of “code-behind” behind ASP.NET web pages. Using ASP.NET I could craft the functionality of each web page using code-behind written in C#. Using Visio Enterprise Edition I designed the class structure of my applications to be. As noted by my supervisor’s final review, I did a fairly good job of separating the applications user interface from the applications funcalityion. For instance, I designed three classes which were solely dedicated to communication with the SQL database using ADO.NET. Each method in said classes returned a data set of the information requested at the time.

Since Microsoft’s .NET is an ongoing technology, is an only recently been accepted by the AOT department. Likewise there are many ongoing issues and discussions the department is having to this day regarding how to design and implement web applications using .NET. One of the more hotly debated issues I took part in revolved around the standardization of custom ASP.NET controls, such as DataGrids and Repeaters. ASP.NET DataGrids are highly functional components that, as is, are very plain and are not tailored to a specific application or typed data set. Since many of the DataGrids are reused throughout an application, it becomes tedious to have to write the HTML and configure the DataGrid manually. While each AOT developer has their personal preference, I chose to create an abstract static class named Controls.cs. The Controls class contained methods to alter the properties of any given control, whether it be a DataGrid or a TextBox. For example, a call to Controls to take an ASP.NET DataGrid and setup it’s properties would go as follows:

Controls.Configure_DataGrid(this.dgEmployees, 700, 15, 10);

My applications started to come along very nicely in the beginning of July as I became more familiar with my development environment and the .NET architecture. Soon I could create fairly complicated stored procedures that contained error checking and followed all necessary business rules in just a few minutes. Just as quickly as I would create the necessary SQL backend functionality would I have my application connecting and “talking” with the database in the appropriate manner.

During the course of the summer I did receive one training opportunity which involved Microsoft Certified Developers visiting the AOT department to give all of us a tour of the .NET framework. The visit didn’t go over very well with my department as the issues discussed by the trainers were usually very basic and did not cover the more advanced issues and concerns we had. The question and answers session was fairly useful, however, and it felt somewhat gratifying when the trainers learned that I was an intern taking part in such discussions.

Once initial development was finished for each application, I would have my supervisor approve that the application was functional and did not contain and SQL stored procedures which could possibly damage the integrity of the database. After doing so, I would move the application to the next environment, or the “test” environment. Usually this called for copying the .NET project to the “test” computer, known as AOT-TEST-DELTA (which I had personally setup the summer prior), and notify Elissa, our primary application tester, to set aside some time to test the application. At the same time, it was necessary to update the SQL database with the next build which contained all of the SQL functionality necessary for the application to run properly. This period was the most stressful of all as many tasks and issues crop up when the time sensitivity is usually very high. Each transition to the next environment (development to testing, testing to production) was considered a milestone but only helped to increase the tension associated to these transitions.