Refactoring from Back to Front; Routes Which Cannot Be Traveled

Whether it be ordering food, news, entertainment or writing this very paper, software is ubiquitous in our everyday lives. For this reason, both the technical research report and STS report heavily involve software development practices. The technical research report details my experience and work done at Capital One, refactoring a multi-layered in-house application. The STS report is a case study of the United States Postal Service’s (USPS) implementation of dynamic route optimization (DRO) and how poor software development practices led to its failure.
The technical project consisted of refactoring the retrieval of select information, specifically the reduction of duplicate code. Data retrieval was routed through the “microservice” layer instead of directly accessed from the backend, centralizing backend specific code. As many of the variables changed due to a versioning up of the API, a feature-toggle was implemented in order to adhere to the software development practice of always having a working production. Once the changes were made, they had to pass a suite of functional tests and be merged with the repositories, however, as each layer was its own repository owned by a different team, merge approvals led to several delays. Finally, all three layers were simultaneously tested during integration testing, before finally being put into production.
The project took longer than the team expected, mainly due to the delays regarding merge requests. Furthermore, while the project was finished on time, monitoring of the backend discovered the consistent throwing of errors when the feature-toggle was disabled, albeit to no effect on application functionality. The issues with monitoring the system however, lead to the immediate rollback of the refactoring, before the issue was resolved and the refactoring was pushed again to production.
While the technical project was an overall success, USPS’s implementation of DRO was very much a failure, and the STS report is a case study as to why. While the initiative managed to reduce mileage, the low adoption rates, at the levels of innovators and early adopters according to Everett Rogers’ Theory of Diffusion of Technology. After close analysis, it appears low adoption resulted from issues of the implementation which stemmed from poor software development practices. To determine this, problems of the initiative were looked at one by one, and discussed in relation with software development practices. Due to the implementation of DRO having many informal practices, much of the sources came from the Office of Inspector General.
Reports from the Office of Inspector General revealed the failure to identify fundamental issues before rollout, identify issues after rollout, and adequately compensate for known issues led to the failure of the system. These issues could have been easily resolved by adequate testing, monitoring and rolling back to the static system, suggesting the presence of poor software development practices. This suggests better software development practices may have been able to save USPS at least tens of millions of dollars in losses as well as avoided major job losses and harm to contractors.
While slow and tedious, good software development practices led to the work done at Capital One being high-quality and resilient, working even despite an unforeseen bug. On the other hand, poor software development practices led to the failure of USPS’s implementation of DRO, harming many workers involved. Although software is often created quickly and haphazardly, it is important to remember that software engineering is still engineering, and thus engineered software should be expected to not only work, but to be resilient and prevent harm towards its users.

School of Engineering and Applied Sciences
Bachelor of Science in Computer Science
Technical Advisor: Daniel Graham
STS Advisor: Catherine Baritaud