Taking on ownership of an aging and waning Rails code base

The client came to me after a long journey with different agencies selling them spot time for partial developments and hotfixes. When I took ownership of the codebase, the latest commits had been upgrading the Rails gems and making them work ad hoc. The application had no functioning test suite, so the upgrade was risky. The main outcome was that Rails idioms and styles had not been updated alongside the gem versions.

Mapping out the codebase was the bulk of the work; the actual upgrade is then only grunt work. The conversation with the client is the most important part. They had been living with the codebase for 14 years, and relying on their real-world experience rather than only the technical reality of the programme was key. Being able to understand and relate to what they focus on is the real work.

The result of the initial conversation, reviewing the codebase, and the infrastructure around the running app was the first deliverable. A report with

• a high-level comment about the app’s repository,
• a list of all infrastructure dependencies,
• a summary of the current open issues, commit message history and branches, and codebase TODO comments,
• headlines and excerpts of six roadmaps for the way forward,
• further findings on public media about the history of the app and the code, the business history

Halfway through I realised that the application code and the organisation around it had pivoted from a portfolio to a competition platform. The break is clear in hindsight, but I could also see in the git history how it had not fully manifested in the development process and feature prioritisation. The biggest debt was the remains of features that were either unused or irrelevant to the business, yet created dependencies and lingering complexity. The code only told the result, not the path to that situation.

After upgrading to Rails 8.1, the next step was to map out syntax updates and standardisation. Standardrb and Herb (HTML+ERB lint) helped with linting and controlling the views. Honeybadger helped point me to the most common errors and the most important parts to test.

I found a lot of code paths and features in the app that the client was not even aware of. The biggest help in clearing the path forward and removing the anxiety of touching the core business logic was cutting unused features (Facebook like/share, a privacy feature, dynamic navbar, participants view, name locking) and dead code.