Does your project suffer from technical drift?

As tools evolve and change, technical drift can slow development efforts. Here's how to deal with it.
140 readers like this
140 readers like this
Yellow arrows going both ways with texture

Photo by Jen Wike Huger

The other day, while building a UI replacement for an MVC application using Angular 5/WebAPI, we bumped into an issue. I thought, "This is technical drift."

Someone posited the term technical drift a while ago. My team has been working with Angular since its infancy (AngularJS), through its teenage years (Angular 1-2), and into its current young adulthood (Angular 4-6). We have developed plenty of knowledge, but we never seem to keep up. This discussion is not about Angular, MVC, Bootstrap, or other tooling. It’s about what we are experiencing in our lifecycle while using this new tooling. The tooling is mutable, and it drifts. Hence our application updates are being affected by technical drift: What looked like about an hour of work ended up taking much longer.

"Genetic drift" concerns populations of organisms that take on less genetic variation over time. This is not a healthy thing for a diverse ecology, but in the digital world, where we want predictability, this outcome can be positive. Understand, though, that technical diversity is a healthy aspect of your portfolio.

This process is taking place in Angular where some of its tooling is changing or disappearing. This behavior is not necessarily a bad thing. It is natural that some tools are deprecated or removed because better ones are created or included. The troublesome result is that we are accumulating technical debt due to this technical drift. The problem is the drift is not visible; it’s below the "water line."

The specific issue we encountered was an Angular pop-up modal implemented using a template-driven approach. The component was watching some textbox events, ultimately querying the database for a list of stuff. If you don’t know Angular, the issue is that an implementation worked at that time and had for several years.

In order to use a debounce method, the app used RxJS classes. A textbox drove through the component to call a server web method in a service to get a filtered result set. In the distant past, a developer was trying to work in the debounce and chose that implementation path. Angular 5 RxJS no longer has the debounce on that particular object. The tooling drifted.

Certainly, if the developer had known this would happen, he or she would not have chosen this implementation (I hope). For you Angularities, we are converting all our apps to use the reactive forms approach. More code, fewer HTML directives—a much better choice for testing and understanding the flow in the application.

My advice is to think about where and when you experience technical drift and why. This will help you understand the risk within the tooling and where your upgrade/update process may be complicated. When evaluating your technical stack and technical debt, think about how much technical drift may exist. If you don’t see or experience any, then you probably have an evolved, stable toolset. This does not mean the toolset is no longer changing, but that it’s mature and in a state to be expanded so you will experience less pain due to technical drift.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.