Skip to content. | Skip to navigation

Please visit us at
Personal tools
You are here: Home Job Opportunities Job/Internship Vignettes and Tips Robert Beuligmann's Internship Experience

Robert Beuligmann's Internship Experience

Company: bswift

During my internship at bswift, I was tasked with the conversion of a new user creation process and the development from scratch of a configurable health questionnaire. To make things more interesting there was a hard deadline – just two months – by which time the system had to be functioning, or one of our newest clients would lose their ability to be underwritten by third party insurance companies. The scope of the project involved taking an existing code base written in visual basic 6 and asp, and converting it to C# and while maintaining all original functionality and incorporating the changes for this new client.

The legacy code base played a pivotal role throughout the project lifecycle, as it was the only complete documentation of the existing process. A design document had been prepared before the project was started and contained the majority of high level goals and requirements for the visual element of the project. The design document lacked depth due to the fact that the design team did not have the time or means to extract existing requirements directly from the code. The VB6 and ASP code had originally been started in early 2000-2001, and had undergone numerous revisions and upgrades during its lifetime.

The code was only marginally commented on by its various editors, and often only served to highlighted code that was easily understood on its own. The components written in VB6 where made more complicated by the fact that there had been efforts to incorporate buzzword technologies, such as XML; primarily, so it could be said that the system used them and not because the technologies enhanced the way the program functioned. One example was in the core component libraries where they were passing method parameters using XML. The result was to make a method call. It required calling a separate core library to encode all the parameters into an XML object and passing the object into the library method. Once the XML object was inside the function, it called the core library again to decode the object and extract the parameters into the local space before doing any real work.

After spending many days reading through the legacy code, it became clear that the system had originally been built around an overall design and not just as the piecemeal system it looked like at first glance. There were core components and dlls where central and often reused features resided, with more specific features residing in their own child components. The components also used external XML files to define the structure of database tables and how to interact with them. These designs all looked promising on the surface. The code that resulted from this initial design slowly became more polluted as successive iteration of the development added more and more functionality, while not completely understanding why the initial choices had been made.

An additional factor in the complexity of the legacy code base was the lack of tools to adequately work with the code as it had been originally designed. To understand how the code was working, it often required multiple sections of code to be looked over at the same time. These files had to be manually searched for the functions and methods that where being called in the other components. The separation of core components for database access and business logic was frequently hard to follow, because the one was often not clear without the other.

The conversion from VB6 to C# had already started by the time I was hired at the company. A collection of around thirty-five unique objects representing all the data a user could have stored in the system was nearly complete when I was assigned this project. These objects could be displayed and edited on web pages by using a reflection based framework that had been created by the lead system programmer. This framework was designed to display and edit objects individually. In order to meet the very aggressive deadline, it was decided to use these existing objects and combine them into a single process for creating a new user.

At the end of the day, more time was spent retrofitting the existing objects into general multipurpose objects then was spent completing the logic for the new process. It also proved time consuming to extend the custom reflection-based presentation code to support having multiple objects on the same page and within the same namespace.

Part of the work I needed to complete was a health questionnaire that could be configured with any number of questions of a known number of types. The system had about forty questions with three different types of questions when the questionnaire went live. Each question could be answered with a NO response, with no further action required. If the question was answered YES, then additional information based on the question type was required. Each YES response could have multiple responses to the same question. So for each question, it could have exactly one No response or one or more YES responses.

The design called for a highly dynamic page with the ability for the users to create a wide range of responses. Designing this process from the user interface perspective focused on providing the user with as seamless an experience as possible. The standard HTML GET and POST cycle would lead to a fractured user experience due the very dynamic nature of the page.

I chose to implement a framework based on a web service model to handle editing and saving data dynamically using AJAX. I created a framework that supported four main actions: display, edit, create, and save. The base of the framework was comprised of a C# ASPX page that had stub functions for the four main actions, plus a front end written in JavaScript utilizing jQuery to provide the AJAX support. Once the framework was in place, it provided a clean break between the backend code that saved and retrieved the data and the page that was being displayed to the user.

By the release date, the revised user creation process was still being actively developed and tested internally. Several key features that had been hidden deep in the legacy code and not documented in the new design had simply not been recreated in the new process and where not found by the Quality Assurance process that was in place. It took approximately two weeks of crunch programming after the release date, to identify and fix all the missing features.

In the end, the experience has taught me to work hard at the initial design and planning stage to really identify clear goals and possible pitfalls that will eat into the limited development time available. The questionnaire has been the most robust part of the entire project – needing no major adjustments since it was launched. I believe it has been a real asset to use the skill sets learned from my classes at Loyola in a live project. I have been able to produce robust and scalable solutions while having to work within the time frame available.

- Robert Beuligmann

Document Actions
« May 2018 »