Looking Past Technical Debt

A one size fits all definition does not exist when describing the personality of a software developers. Though hard to believe, developers are regular people. Some enjoy the sun and outdoors while others hiss at the sun while emerging from their caves. To some, lifting their coffee mugs to drink will constitute their exercise for the day, while developers like Adam Wathan exert super human strength. The point I am poorly making is that for the most part, it’s difficult to identify who is and who isn’t a software developer in a police line up. But there is one trait that all software developers share: a disdain for technical debt.

First Jumping In

Since I started working with Honorlock, the development team has nearly doubled. Over the past year, we have put systems and processes in place to dramatically increase the quality of code that is being deployed to our production environment. But over my first few weeks, as I reviewed the existing code base, I uncovered so much technical debt I started getting bombarded with calls from collection agencies. The Bernie Sanders’ campaign reached out and promised a technical debt relief plan if I pledged my support to the Sanders’ movement. The very next Dave Ramsey podcast included a segment where Dave railed against technical debt and proclaimed we need to stop increasing our national technical debt because the future of our dev children is at stake. We had a lot of technical debt to solve.

The issue is not that the software didn’t work. It definitely did. Honorlock had quickly become a player in the education industry. They were receiving incredible reviews from instructors and students alike. Compared to competitors, Honorlock was offering a solution that solved many of the issues that made online proctoring difficult. They provided an easy way for instructors to adjust the proctoring settings for their needs while also being as unobtrusive as possible to the student experience. Honorlock allowed students to get into their proctored exam in less time than almost all other solutions. You no longer needed to install crazy programs that took over your entire computer and messed with all your personal settings. Even changing your background!!

The Appreciation Stage

As I continued to wade through the technical debt, a realization started coming over me: these guys are incredible. Sure, there wasn’t a D.R.Y. file in the entire codebase. You would often catch me mopping the area around my desk as condensation collected and dripped from my computer. I almost hired a professional NBA court mopper to help keep my area dry. But these guys had put speed and innovation above abstraction and database modeling. They traded event listeners and observers for user experience and accessibility.

I started looking past some of the more convoluted controllers and found the passion and ambition that was baked right into the code. I got it. The how’s and why’s became answered all at once. I was one with the Honorlock code base.

Evolve

This is not to say that there isn’t refactoring to do. There are a bunch of really exciting features in the pipeline that will require some re-architecting in order to implement. We have been forcing ourselves to look at problems and ask, “How SHOULD this work” instead of “How do I force this to work”. It can be nuanced but you quickly start answering the right questions and avoid common rabbit holes of discovery.

When joining a new company or jumping in on an existing project, don’t get bogged down with all the technical debt that “needs” to be addressed. Part of the progression of a software developer is learning to distinguish between what needs to happen and what would be a nice to have. But most importantly, appreciate what brought the code to where it is. It’s not all about design patterns and principles. Honorlock started with an evolutionary idea and flourished into a runaway success (shoutout to my FAU Tech Runway peoples). Besides, who doesn’t like a good refactoring!