Renovate or rebuild?

Let’s look at a timeline for any application. This may seem like a broad generalization, but this is usually how most timelines of new applications go.

At first, you are all excited because you just got a new application. It’s all shiny like a new car and maybe even has a fun new car smell. You start using it and it is working just like you wanted and things couldn’t be better.

Let’s fast forward about 3 years after the initial install date. Now you have been using the software for a few years and it’s still great. All your employees love it because it is simple to use and never gives you any trouble. It is getting a little old, so the overall look of the site, as well as the new car smell, are long gone. However, you don’t worry about it because it’s still only a few years old and works great.

Now let’s fast forward a little more. Now the application is 6 years old. It still works pretty well. It has a few issues that spring up from time to time, mostly when someone is saving something new. The app also seems to be getting slower when it calls up the initial load page, but nothing that you cannot live with. After all, the application is only 6 years old so it’s still good for another few years or so right?

Now, let’s look at the application at it hits 9 years old. The application is definitely older now and it looks like it. The sleek and fun design now looks very dated but the application still works. Sure, the page loads overall are slower. When you first call up the application you usually have to wait for a few minutes, but you only have to do that once per day. It’s still working fine for what is needed (as long as ‘fine’ is waiting for a couple of minutes per page) and you know you can get another 4 years out of it.

As a developer, this situation has shown itself plenty of times. The developer hands off a new application and gives it to the client who installs and runs it. The client starts to notice little things going wrong after a passage of time but doesn’t think anything of it since they don’t want to pay to get something so minor fixed. They may even say to themselves, ‘those developers worked so hard on this and if I call them and complain, they’re just going to think that I am being a complainer.’* They live with any overall issues because they don’t think of them as a big deal.

*I HAVE HAD SEVERAL CLIENTS TELL ME THIS EXACT THING.

Let me ask you something before we go any further. When would you have contacted the developers with concerns about this theoretical application? I know you are saying you would after 3 years, but would you? When it is laid out like this it is easy to see how that would be the logical time to contact someone because you can see how the problems only get bigger and never go away. It’s also not correct either. The best time to contact a developer about application improvement is as soon as you see or experience something that needs to be fixed.

However, that is almost never the time when someone does it. For as many clients contact me after 2 years to have software adjusted, I have twice as many that contact me after year 9 to ask me what could be done to fix the application. It goes without saying that when the application hits this stage that there is really not much to be done. At that point, you are into a situation where to get that application running fast again, you are going to have to rebuild that application.

Generally speaking, technology moves pretty fast. Computers generally double their capabilities every 12 to 18 months. When you wait for 3 years to get an application tweaked, you are already around 2 years behind technologically.

When you get applications that are older than 5 years and not updated, you have a multitude of issues. The underlying technology is probably pretty old (technologically speaking) and with age, comes danger. There is an ever-present danger when it comes to applications that are running older technology. As they get older and not updated, they become more vulnerable to bigger problems that having older technology brings with it.

Make sure to always be mindful of your software’s age. Also, make sure to always contact your developer if you think something is wrong. I don’t know any developers who would rather find out about issues 5 years after the fact. If you think there might be something wrong with your older application, you are probably correct and you need to get in contact with someone who can fix it