The last 18 months have been very interesting at Dash Point Software, Inc (my company). Our team has been involved in rewriting two major applications for a client. This has been an eye-opening experience for our team. The first of these systems is a payment-processing system that we converted from Ruby on Rails to WPF/C#. We were the original developers on this system so it made perfect sense for us to handle the conversion. The second project was to convert a business-critical website from ASP.NET Web Forms (pre-master pages, to give you a time reference) to ASP.NET/MVC. Each of these conversions had number of new features added while they were being converted.

Lesson 1: Conversions are Harder Than Meets the Eye

Converting old code can be more difficult than writing code from scratch. During this process, we grossly underestimated how much time it would take to convert code. This was particularly true for the website application. You'd think with an existing code base, it would be simple to take one set of code and convert it to another. That's a nice thought. ?? In the span of 10+ years, lots and lots of features are added, changed, orphaned, and simply tweaked. Every one of those changes required unique and individual decisions on the part of the designers and developers. Some of the features were better documented than others. Converting this code took painstaking effort to understand the intent and to make sure that intent was managed in our new code properly. This effort took much more work than we anticipated. Which leads us to our second lesson….

Lesson 2: Set Realistic Goals

There's a trait that most developers have: We are eternal optimists. Given enough time up front, we feel like super heroes and can accomplish anything. For each project, we started with a deadline in mind and felt positive that we could accomplish the tasks at hand. In each case, we were wrong. Each project missed the deadline by six or more months. How do we, as developers, combat the chronic lateness of our projects? One idea that we're looking into is to start working on a project for a month or so before attempting to estimate the real time to completion. In one case, after a challenging four months of hardcore development, we knew we weren't going to make our deadline. At this point, we took a pause to come up with a realistic set of tasks remaining and worked on a realistic timeframe for completion. We did a much better job of estimating what was left and hit our goal within a few weeks. Setting realistic goals is a challenge for all projects and one we strive to improve.

Lesson 3: Work/Life Balance is Important

Many nights of sleep were lost on the Web project due to the effort of trying to meet the unrealistic deadline. When the team stopped to re-assess our deadline, our senior project manager told us to make sure to add in our vacation/downtime into the timeline. “Don't kill yourselves over this,” I think she said. When you're knee deep in getting stuff done, the idea of downtime can slip out the window. Taking proper care of our team helped to insure that the deadlines were met while keeping our sanity.

Lesson 4: A Calm Team Gets It Done!

The day had finally arrived: We were going to ship our product! We turned off the old code at 9:00pm and started on the task of turning the new code. The team expected to be done by 1 or 2:00am, max. Well, at 11:30am the following day, we were still there. Every deployment has problems. Configurations were missed, network settings were incorrect, data conversions took longer than anticipated, files get missed, etc. As the saying goes, stuff happens! It's the attitude of the team that makes all the difference. There are two courses of action. We can freak out and declare that the sky is falling or we can remain calm and work through the issues. Our team did a marvelous job of the latter. We remained calm and as each situation presented itself, we took careful measure of the issue and set about fixing the problems. One by one, we fixed our issues and the software stabilized. Not all of the issues were resolved in the first 48 hours. Some of them took days - and in some cases weeks - to fix properly. Eventually, we shored our systems up and things are progressing well today. I firmly believe that the team's calm and measured demeanor helped us greatly.

Lesson 5: Monitoring Tools Are Invaluable

One of the saving graces in this deployment was the tools we used to monitor our software. We used a lot of them. Our SQL Server gurus used monitoring tools to tweak queries that were fast in UAT (User Acceptance Testing) but slow in production; we used other custom scripts to watch our data connections and other metrics. Finally, we used a tool that monitored the error rate of our application. This tool helped target unseen errors in our application, helping us further improve our systems. Without these tools, it would have been much more difficult to stabilize our systems in a realistic timeframe.

The Final Lesson

When building and deploying software, it's important at the end of the project to take a bit of time to reflect on what went right and what went wrong. Spend the time being introspective. Taking the time to do post-mortems on projects will help you improve your process and insure that the next one goes better.