You ever worked on a beastly project? And by beastly, I mean large, enterprisey, many fingers in the pie (3+ active rails developers), non-sexy (not social, not using NoSQL, not using Rails 3) project?

I have. And this project possessed no inner beauty.

More specifically, our team worked with a Rails code base of 25K+ lines of application logic with a 1:0.2 code to test ratio that has seen four different companies (25+ different committers!!!) working on it in the span of three years and was in the middle of merging with another large codebase. Yikes!

With an enterprise level merge occurring, communicating and coordinating model interface changes with other devs challenged us the most. We couldn’t rely on a strong test suite to indicate when we’ve broken other aspects of the app so there was no room for Aliens style refactoring.

“… nuke the site from orbit. It’s the only way to be sure.”

As fast as we worked to increase code coverage, we also had to be pragmatic. Deadlines loomed and they couldn’t be ignored.

Is there anything more frustrating than the interface for an object changing out from underneath you, breaking code on which you’ve been relying?

Our solution? Implement application specific DEPRECATION NOTICES.

How do you handle managing change in a legacy rails codebase? Do you like the idea of application specific DEPRECATION NOTICES?