Transferring Project to new Team

So one of the projects at work that I built from the ground up and had developed for well over  a year had to be transferred to a new team.  The application is a ASP.NET web application that is used by a number of people at work on a daily basis to enter important observation data.   When I heard from my supervisor that I was no longer going to be working on this project I felt sad as I had become attached to the code.  I also had some anxiety in sharing the code with other developers as I was not sure that my code would fit their requirements for robustness and clarity.  I also felt that because I was familiar with the code base and the size of the code base (close to 20k  lines of code) that the development/enhancements of the project would come to a halt.

When my boss sent out an email to everyone in IT regarding a job to create a simple data entry application I immediately jumped at the opportunity to take on a new challenge.  The initial one-on-one conversation with users went great and I knew that this application was going to more then just a simple ‘data entry’ application. I thought about the design I was going to use for a few days and then with the requirements in hand I started to build the application. In a matter of a few days I had a working application that I showed the users and they were satisfied with the product I built.

While I happy overall with the application, there were some decisions I made about the project that I regretted:

• Custom Authentication – Although I knew that ASP.NET had a built in Membership Provider (used for authenticating users) that I could have extended, I did not.  The reason for this was time, I knew that I had a tight schedule and I needed to build something right away so I built my own custom authentication system.  The authentication works well (there was one bug that I found early on but I was able to fix this quickly) and the users were happy with the speed and ease of use of it.  I wished I had invested a little time on on how to extend the Membership Provider (as well as the Role Providers) provided by ASP.NET it would have made my work so much easier in implementing some of the features requested by the users.
• Custom HTML – This was my first web application that I had built from the ground up and at the time of me doing this my HTML skills were not polished as I would have wanted them to be for a project like this. This resulted in the html interface having some quirkiness to them that I just didn’t anticipate.  One of the things I was working on (before transferring the project to a new team) was cleaning this up and even began a new branch in git to use a html ui framework to clean this up but was not able to merge my changes back to the master branch as I had other pressing issues with the code (i.e. refactoring, adding new features and bug fixes).

When I got the news that I was going to be giving the project to a new team I was in the middle of a major refactoring of the application. When I first built this application, there was very little in the form of organization of the application which caused issues later on as the size of the application grew.  From the recent experience with another project I was working on (which was organized much better) I took it upon myself to create a new branch in git and start the process of cleaning things up!  As you can imagine, this was a tedious thing to do but with the help of some of the built-in features of .NET I was able to move the code around without any problems (you can read more about this in a previous post).

Even though the refactoring was a success, I still had one lingering fear about the codebase. This being my first project where I developed everything on my own I was afraid that the new developers would not be able to understand the code or the architecture of the application.  I thought that the new developers were going to hate the code which was completely foreign to them!  Luckily this was not the case! The developer that got my codebase was impressed with the quality and consistency of the code!  This was a huge relief on my part as I was happy that all of the hard work and long hours of refactoring paid off!

Since I had been working on the application from the start I was (and still am) very familiar with the architecture of it.  When I would get requests or questions from the users I knew exactly where to look at in the code to get the answers for the users and implement the features that were requested. I knew that the new developers would not have this available to them immediately which would cause delays in bug fixing or adding new features.  This unfortunately is what is happening now.  I’ve gotten reports that the developers of the application have not built the requested features or fixed bugs in the application.  This really made me sad as I knew that it would happen.  The development of the application is now stalled, I’ve yet to see any new features built for it and the features I have seen built have taken a long time to build when it would have taken me much less time to build on my own.

Luckily, I’ve been asked not only by the users of the application but also by the developers of the application to be involved in some of the discussions of the development of the application.  I’ve assisted the developers in fixing up some minor bugs and also helped in enhancing the existing features of the application.  This is an interesting position to be in, but one that I am relishing on as I am helping out both the users and the developers of the application. My hope is that the application continues to grow with enhancements and fixes so that the users who use the application don’t have to use something else (they were using paper and pen before the application).