Into The Development Time Machine

Imagine working on a brand-new project using the latest version of Java to build RESTful APIs on the back-end and AngularJS as the client. To make things even better, the front-end is supplemented with Bootstrap UI and a host of components to provide a well-polished, responsive application. The project is following a Scrum-based agile software development methodology, you have a dedicated resource from the business, and your team is in the Performing stage. Clearly, life is good.

The rumor mill is churning. Word spreading fast is that changes are on the horizon. In short, one of the legacy applications is costing too much and an executive-level decision is made that a replacement has been selected. The decision is also made that your team is the team who will be working on the conversion.

Not too long ago, that became my team's reality.

The selected application is a name that I recognized, but I will avoid mentioning the product here.

I had read about the product briefly in the press and heard about it over the airwaves, but my team had no experience or real knowledge of the solution that had been selected. We were excited to learn about this new product, as there was a lot of excitement from the higher levels of the organization about the change in direction.

Not too long after the team dove into the product and participated through hours of online and instructor led training, the reality hit us like a brick wall. We realized that the series of sprints were not going to be the same as the prior sprints. We had looked under the covers and realized we had been transported to a platform that is using concepts and patterns that were popular over ten years ago.

Ten years ago? Seriously?

Yes! Ten years ago!

At this point, we felt that nervous feeling in our stomach as we watched the other agile teams continue to strive forward on that way-cool, latest-and-greatest-technology application. I personally felt like Michael J. Fox during that scene at the end of Back To The Future 2 when he remained in the past as the time-travelling DeLorean disappeared into the sky.

After taking some time to vent during the first few retrospectives, my team accepted our fate and focused on getting the solution in place. We were trusted and proven professionals. We were picked by senior management to take on and complete this task - because they had the confidence we could do it ... and do it very well.

The challenge to work with a dated platform was not as easy as any of us imagined. I felt like I could just put my mind into "2004 mode" and go from there. That did not work, because my mind has moved on from 2004 and wanted to solution like it was 2015. Kind of like trying to un-learn a lesson.

In the end, it took the help of Google search, something we called "Stack Overflow Driven Development," and several cases with the product's support service to develop productive results in our new world. While the design limitations would be an instant reminder of the dated technology, we continued to push forward to reach our goal.

Then, I discovered the epiphany, which is the moral of this article.

As we watched the end-users attend training and begin using their new system, we noticed a common theme. They loved their new application.

Seriously? They loved it?

Yes ... THEY LOVED IT!!!

How could this be? The application was so dated, so unresponsive, so 2004.

Turns out, the end-users did not care about any of those things. The application that our team designed met their needs and exceeded their expectations. All the things which caused us to cringe never hit their radar - especially when compared to the legacy application they had used for last several years. The end-users were beyond happy. They loved their new application.

I wondered how much happier the end-users would be if we would have built a new responsive application using Java, AngularJS and Bootstrap instead. In this scenario, I believe the gain would be marginal at best. Certainly, the time required to build something from the ground up would far exceed the amount of time it took the team to customize, extend and configure the product that was purchased. In the end, we were able to deliver a solid solution at a very fast rate - both of which made the executive leadership quite happy.

It is common to equate the age of technological components toward a successful or unsuccessful solution. In many aspects, this is probably true. However, the view from the customer (or end-user) is an important metric that should not be ignored.