Desktop App Enhancement Leads to Rebuild

A new client decided to try us out on what looked like a simple enhancement project, but implementation brought additional issues to light. They found they could trust us with a rebuild that required exploring and anticipating beyond the task at hand while maintaining a commitment to on-time, on-budget delivery.


As a worldwide manufacturer of electric motors, our client converts power into motion. When they engaged us we were inspired: As coders we like to make things run, so supporting a company that does just that, while maintaining a stellar reputation for integrity and quality, seemed like a great match. The company empowers its 20,000+ employees toward new ideas and innovation on behalf of customer satisfaction. We were impressed with the company and culture and eager to help.


The client gave us a task that would give them an idea of how we worked. They had experienced poor outcomes with vendors in the past and were hesitant to engage us. Of particular frustration for them had been letting down internal departments who had been counting on them for enhancements and functionality, because an external partner had failed to come through. They assigned us a project that was highly visible but not intended to be overly complicated. This way we would have the chance to prove ourselves to the internal team and stakeholders, and they would have a chance to assess our skills and commitment.

The project focused on usability of a desktop application that the client’s customers use to configure and control electric motors in heaters, water heaters, and air conditioners. The app is used within the supply chain (not by the end consumer) to change the behavior of the motors such as increasing or decreasing the speed, or changing the rotation of the motors from clockwise to counterclockwise. The major problem with the app was usability. The existing app did not support modern design and the client’s competitors had apps that did.

The software was originally written in VB6 and needed a UI/UX facelift. The client’s internal developers were focused on multiple projects and sought outside skills specific to desktop development and WPF. Our job was to revamp and modernize the outdated UI/UX of the existing app and make it compatible with modern Windows versions. The intent was that we would use components in their current state and would not change business logic. For instance, we would take an old component from the old app and embed it into the current solution, just changing the UI. In addition, to improve efficiencies we would be adding test automation to the software.


We set up an Integrant team that included a technical project lead and a team of developers and SQEs. On the client side, we worked with a hands-on technical lead and the head of engineering, both of whom were technically knowledgeable, business savvy, and available. The technical lead was a new hire and working with the Integrant team would be his first implementation for his new employer. We all had a lot to prove and we were fired up to get it done.

We started by reviewing the existing application and set a technical approach and strategy for the revamp. We studied requirements of the app, we studied the business, and created a high-level work breakdown structure and estimation. With the client and Integrant as one team, we agreed on a five-month timeline starting in mid-November with completion by end of April.

Each sprint was three weeks, and we demo’d progress to date with all stakeholders every two sprints. We held two client-Integrant status meetings per week (on Tuesdays and Thursdays). In addition, we had daily interaction with the client via Skype and other tools.

The initial phase involved a month of planning. We started with the existing UI and quickly notified the client-side technical lead that we needed to add a usability expert. Our UI/UX engineer sped up the process and enhanced the current UI by making changes to improve usability. We also implemented an interactive wireframe using Axshare. Axshare allowed us to share wireframes with all stakeholders, receive input and comments, and make modifications until we were ready for implementation.

When we started to really dig into the code and technical design, both the client-side technical lead and the Integrant team had some concerns. The following risks became evident when it came to updating and applying enhancements of the new UI:

  • The original app had been written in VB6. This programming language and technology do not support the full object oriented context used to implement desktop applications. This meant that we wouldn’t be able to take the existing code and incorporate new UI/UX without applying modifications.
  • The configuration variables were hard-coded. This meant it would be risky to apply modifications or to fix bugs.
  • Some programming functions contained more than 200 lines of code.

But identifying the need for a rebuild of the app that controls the motors, and deciding to pursue the rebuild, are two different steps. There are risks attached to a legacy app and there are risks attached to a rebuild as well. The existing software controlled electric motors and though it was outdated, it functioned.

We weighed the pros and cons. In the end, as one team, we agreed that choosing not to rebuild the existing app now would only increase the effort and overall application maintenance cost in the end. The client had a lot on the line; this was a high visibility project that had started relatively simply and had grown significantly. We were still an unproven entity to the internal team. Also, this app was tied to multiple other projects that were contingent upon successful completion of this one.

The client decided to take the risk and move forward with us based upon several factors including:

  • It had become clear that a rebuild had to be done at some point. Because we already had the “patient on the table” so to speak (Integrant was well into and engaged with the app), addressing the problem now, if done right, would save time and money in the future.
  • Our solution structure covered modularity.
  • The client had confidence in the way we wrote code.
  • The client trusted our code policies and standards.
  • The client felt we understood and shared the gravity of the project and that we would come through for them, no matter what.


The client needed to stay within the originally planned timeframe because there were many programs dependent on the successful and on-time launch of the tool. If we missed the deadline a suite of other projects could not launch. The app needed to be up and running by the end of April, whether it was simply a UI/UX enhancement or a full rebuild. To accommodate the client’s priorities we infused more talent into the Integrant team rather than stretching out the timeframe. Because we structure teams around pre-existing synergies, we were able to add team members who were already familiar with their teammates and the technology. This meant there was a low learning curve and velocity increased exponentially with the new team members.

The Integrant team structure changed as follows for the remainder of the project: We moved the UI/UX engineer off the team and moved on 3 more developers and 1 more SQE. The client contacts remained the same. With each sprint the client team and associated stakeholders saw additional features, each architected and built the right way. They slowly gained confidence in our ability to come through.

Some details about the rebuild include:

  • We rebuilt the app in C# and used WPF (Windows Presentation Foundation) to implement the UI. We used WPF to unify a number of common user interface elements that could then be linked and manipulated based on various events, user interactions, and data bindings.
  • We used MVVM (model–view–viewmodel) pattern in order to design a solution with modularities, separating business logic from UI and so on. MVVM is a software architectural pattern that facilitates a separation of development of the graphical user interface.
  • We used Telerik for UI controls. Telerik provides ready-made controls and this saved time.
  • We used Microsoft’s Prism framework, a powerful framework with readymade features that helps apply MVVM design pattern while using WPF for user interface. Prism provides guidance in the form of samples and documentation that help you easily design and build rich, flexible, and easily maintained Windows Presentation Foundation (WPF) desktop applications.
  • For automation testing we used Coded UI. The testing specifically covered read/write processes to and from the motors.
  • The app is deployed in the cloud to allow continuous updates. Our system notifies the user if the app version they are using is an older version than the one in the cloud; if so, the user is prompted to update.


The next phase of this rebuild is the development and test of a mobile version of the software. This will allow remote access control and configuration of the motors. Currently the user has to connect the motor to a laptop. This phase will allow the user to configure without being present physically. We will use Xamarin for dev and test due to its efficiencies in time and resources and coverage.

Just as our client’s success is based upon turning power into motion, our job is to turn our skills into solutions for our clients. Our greatest pride with this project was our ability to come through for a client that took a risk with us. We look forward to a long-term partnership.

If you want more on legacy rebuilds check out Legacy App Rebuild for Medical Manufacturer or Legacy System = Caution Comes First.