Always-Up-To-Date Development

I recently had a discussion with a member of my team on when a startup should update to newer versions of software that is part of its technology stack. More specifically, we were discussing whether we should update some of our web applications from Rails 3.0 to Rails 3.1.

We ultimately concluded that there was no reason not to do it as quickly as possible. Otherwise, we felt, we would accumulate more technical debt, and it would become harder and harder to upgrade in the future.

I remembered what a friend of mine at a Berlin-based internet startup had told me, confessing that they were still using a very much outdated version of the Rails stack (some 2.x version) and that they would have a really hard time upgrading to the latest version. They had actually built most of the technology that is part of Rails 3.1 today themselves—long before the Rails team included it in their backlog. For instance, they built their own custom asset pipeline.

Having that custom code was great while Rails wasn't supporting it natively—today, it is not more than a drag and a duplication of effort. Keeping the old codebase clean and effective becomes more and more difficult, and in the meantime the barriers to an upgrade to the latest version of Rails climb to ever-greater heights.

Coming to the rescue: always-up-to-date development. Make it part of the development process to upgrade to the latest version of each layer of your technology stack whenever there is a substantial update. Should it appear to be costly to upgrade, give the upgrade an even higher priority—because every cost you do not take on now will have to be taken on in the future, only magnified.

Take your time to rewrite parts of the code to use newer features. Get rid of code that can be removed, now that the new version allows the same things to be done in simpler ways. It will pay off in the future to constantly stay ahead of time.

That said, the always-up-to-date development philosophy should not be taken as dogma. Decide whether it makes sense in your particular case. Just like technical debt may be embraced with open arms, deprecated code may be as well. It depends on the code.