On Messy Codebases

What follows is my personal experience related to this LinkedIn post: it’s all good until the dominant values of a group change with staff turnover.

In early 2018, our project had some critical features built using Vue.js. In hindsight, the decision to use Vue.js wasn’t carefully deliberated: everybody (me included) was convinced we needed to use something that would support a complex UI. We needed to learn Vue.js quickly while building out these critical features. What initially was thought of helping to speed up development turned out to be a liability. Everybody (me included) seemed to know that using Vue.js for this project was the wrong choice, but did not stop primarily due to loss aversion and the lack of a suitable alternative.

At this point, the dominant group of developers has built a Vue.js frontend with all the supporting code needed to render these single-page applications. The team proceeded to build more features on Vue.js (I failed to constrain its scope), which continued until these developers started to leave. This was also the time we addressed bugs with the Vue.js code. The developers left to fix the problems were not the same developers who built the features, which led to time that needed to be spent on knowledge recovery (figuring out how things work) and applying fixes.

In mid-2018, difficult conversations started between our client and the team regarding quality and delivery pace. We decided we needed to stop using Vue.js and look for a suitable alternative that did not require a steep learning curve. At this point, the codebase was a mess to figure out, but it was workable due to the tests we’ve started to prepare for the critical features. A new dominant group has since emerged, which valued maintainability and remembered what came before. The new team had to work on a controlled mess: keeping the existing Vue.js implementation working while building an improved replacement in the background. This team also had to continue to deliver value to the business while rework is being done. The new team also was less than half of the size of the original team, which meant that the new structure had to be distilled into a set of patterns that new developers could grasp.