A software project is like a house.

To keep your house in a good condition you have to clean it every week. From time to time some things will break and you have to fix or to replace them. But most of the time a quick paint job for the doors and the windows might be enough.

If you take good care of your house, people will like to spend time in it.

But now imagine you are leaving your house to itself. In the beginning the house will still be in good shape and everything will work as it should. But once no one is there to sweep the floor or take out the trash it becomes dusty and dirty. Then after a while things start to break. At first only small and unimportant things break, but one day a big storm hits and breaks a lot of things.

If nobody is there to fix the broken stuff, the dilapidation continues.

After a while the house is in such a bad shape that nobody wants to go there anymore. People will tell you it’s cheaper to build a new house then to fix the old one.

The same is true for any software project.

Assume you are working on a software project with a team of 7 people. Every week they add new features and bug fixes. As the project grows they do some refactoring to keep the architecture clean and without workarounds. They do migrations. They update their software libraries from time to time to take advantage of bugfixes, security fixes and new features.

But then suddenly development stops. Maybe somebody at the top decided not to spend more money on the project. A decision maker says: “The product is working. We just keep it running, but we will not spend more Money for new features.”

And so it comes that the team is assigned another task and the software project might run unattended. The project is now live and is used every day in production by real people.

After a couple of years suddenly the payment process is not working any longer. What happened? Nobody touched the code base in years. How can it be that now suddenly it doesn’t work anymore? How is it possible?

While nobody was watching, a storm was coming up…

You have to know, a software project is not a closed universe anymore. Almost always do software projects interact with the outside world. Software depends on an operating system, on hardware and mostly on a database or some kind of backend. Nowadays even on external APIs. These all are moving parts and they keep changing. And so your project has to change too, to keep working properly.

In our example the European Union had passed a new law to unify the different money transfer formats in Europe. That’s why old payment APIs might not work any longer in the near future.

That doesn’t look like a big deal. Our decision maker decides to hire a Ruby developer to fix the problem. It’s a Ruby on Rails + MySQL project. Nothing special. A Ruby developer is found quickly and his first estimate is 1 or 2 days of work.

The Ruby developer then checks out the project and he realizes that it’s an old project with Rails 2.x. Not Rails 3.x or even 4.x. No! It’s 2 major versions behind. And he never worked with such an old Rails version.

The next surprise is the MySQL version 4.0. Not 5.0 or 5.5. No! One major release behind. The mysql driver gem in the project has a native extension, which can’t be compiled on his dev machine because his gcc compiler is too new. So he has to downgrade his gcc compiler to be able to install the old database driver.

I’ll stop right here. But you get my point.

Because the project was not updated for many years even small changes become very painful now. A minor bug fix which shouldn’t take longer then a day, takes now more then a week. And the Ruby developer is not enjoying his work at all. Other Ruby developers can play around with new fun features like “Turbolinks” in Rails 4.x and he has to deal with this old crap. He will recommend to throw the project away and to rebuild it from scratch with current technologies.

The lesson is clear. If you leave your house for a couple of years you should pay a cleaning lady once a week to keep your house in good shape. In the world of software development that means you should invest a bit of time every week to check and update your dependencies.

Sometimes there are no updates and nothing in the outside world changed. In that cases the job is done in 5 minutes.

Most of the time there are new patches and minor versions available for the software libraries you use. In that case you have to update and see if the tests are still passing and at patch and minor updates they usually do. That’s usually a 20 min job and is totally worth it because these updates bring bug & security fixes and new features. Sometimes even memory and speed optimizations.

Every couple of months there are new major versions available for software dependencies like databases and APIs. Adapting them takes a couple hours, sometimes even days. But it’s worth it because these updates keep your project fresh and it’s the best way to attract talented developers in the future who want to work on recent projects and not on legacy code. Sometimes the updates are not optional, if you don’t update your application will simply break.

Continuous Updating is a method to keep projects alive, healthy and fresh over years. That ensures that even complicated changes of the business logic can be implemented any time in a reasonable time frame with a reasonable budget. Continuous Updating is like a health insurance for your project.

If you are interested in continuous updating you might be interested in design erosion as well. I can recommend this paper “Design Erosion: Problems & Causes” from Jilles van Gurp & Jan Bosch.

How do you deal with “old” or “dead” projects? Let me know what you think in the comments or join the discussion on Reddit.

On Twitter use the hashtag #ContinuousUpdating.

By the way. I’m working on VersionEye, a notification system for software libraries 😉