I’m in a bit of a lucky position with Rainbird at the moment insofar as we’ve recently gutted the core tech and are replacing it with something slightly more durable. While aware we’re under very tight time constraints, I’m also aware that this needs to be done properly.
Ordinarily I would be stuck with the fact that the codebase was legacy and unwieldy, or that management didn’t buy into the changes, or that The Business would rather invest in new features than reworking existing stuff that works… for a given definition of works. In Rainbird the codebase is small enough that we can make these changes, I am management and The Business instigated the change. Win!
While I’m a great believer in agile methodologies, including constant refactoring of code, I’m also a realist. Best will in the world the foundations we lay here are never really getting touched again. The TODO’s will remain just that and any technical debt will simply be baked into the system. We’re not talking about a huge amount of code here; but it’s critically important. Everything we build is being built on top of this.
So we’ve made a conscious decision. We’ve spent a bit longer than perhaps we might have done with other parts of the code base. We’ve spent time on deliberate discovery. We’ve had the hard discussions about the language of the domain and the semantics we should be using. And the whole thing is wrapped up in a little bow made from automated tests and static analysis reports. It’s cost us about 4 days. Maybe 5. It’s going to save us weeks, if not months in the future.