How Do You Know When Your Custom Software Needs a Rebuild?

p>These days, so many companies are running custom software as a tool that is integral to their business. However, many of these platforms are now old and are starting to show wear. A chunk of our projects these days consist of taking old, unstable software and rebuilding it.

The idea of rebuilding a framework that, in some cases, is essential to how a business runs is scary. Like everything else in the world, eventually, everything reaches its end of life, and software is no different. The secret is knowing when to replace what you have and going about the redevelopment correctly.

Of course, this is easier said than done. In this post, rather than focus on how you should redevelop software (a topic of a future post all to itself), we will focus on some telltale signs that it might be time to consider a rebuild.

Rebuild projects don't need to be stressful, but when they are conducted under duress, they can quickly become that way. To avoid that, it's essential to understand the signs and other indicators which may make it seem like your software is ready to be rebuilt.

Is It On-Premises?

For this point to make sense, let me first define what on-premises means. For the most part, this relates to software installed on a local server or local workstations. Typically it's installable and runs as a compiled package.

Before anybody gets upset, let me say there are many use cases where the software should run on-premises. I'm never one to say that one-size-fits-all. However, in my experience, so many companies are running software built twenty years ago that's running locally and should consider moving online to the cloud. Exceptions to this rule are when there may be security concerns or other data privacy worries. For example, nuclear missile silos still run off floppy disks. It works great and is super secure because it's not online. That makes total sense.

However, too many businesses are still running homegrown software in-house on-premises. This approach is no longer the best choice for common scenarios. Compiled software has a slower development cycle, is very difficult to integrate with third parties, it is not portable. Today, web-based software solves all of those problems. With so many people working from home or remote one way or another, web-based software is more of a requirement than ever before.

If you are using on-premises software and have made it this far, you might be inclined to keep going as long as possible. However, as operating systems evolve, so will the tools used to make software. At some point, you will get stuck and have to look for alternatives. It's always better to begin a development process before you're forced to, so I encourage companies utilizing this method to start thinking about redevelopment.

Documentation is a Mess

While being on-premises is a technical and architectural issue that must be considered, documentation is a best-practices issue that oftentimes can be a top-level indicator that things are not as stable as they could be.

Good software should always be documented. Frequently, documentation is an area where clients either want to save money or developers want to cut corners. Having software that's adequately documented - and that means continuously being updated as the software changes - is an essential component of the software development and maintenance strategy.

One need not be a developer to recognize if software is documented correctly or not. One easy indicator to check is the date and timing of when the documentation was created. If the software has been running for many years, yet the documentation has not been updated, that's a problem. It could indicate that whoever maintained it was not following best practices in other areas.

Overall, proper documentation should outline what components are powering software and how it has evolved. And by the way, documentation should also exist in the code. Not all developers like to do this, but it is always something that should be added to a project when time and budget allow.

Tech Stack Can't be Upgraded

As a quick refresher, web-based software always requires certain services running underneath it. A typical LAMP stack would mean Linux as the operating system, Apache as the web server, MySQL as the database, and PHP as the scripting language. It is attached to many other software packages that enable these tools to work together. If the software that runs underneath your framework cannot be updated, that's a sure sign that it's time to consider what your next steps are going to be.

Each of these individual components requires updating. Much like any other software, new versions come out to address flaws or security concerns. However, those updates can sometimes affect the overall behavior of what was built using those tools. PHP, as an example, has changed over time, with some functions removed and others added. This is a natural evolution of the language. However, those who have not kept up with these changes are often in for a nasty surprise when they try to upgrade. It breaks everything.

To maintain conformity with these tools, you must continuously upgrade your code as the underlying systems change. If you haven't been doing this for some reason, it will make all sorts of updates very difficult. If you cannot update the core software on the server, you will be exposing yourself to security vulnerabilities, which is what the majority of incremental updates are targeting. This puts you in a very tricky spot.

If you were in this position, you have two things you could do. You can begin to refactor your code, which is a fancy word for rebuilding certain parts of it. Doing this can bring it up to a level of compatibility with the most recent software libraries. In the worst-case scenario, this reason alone can result in a rebuild.

The quickest way to diagnose your situation is to run an audit of your server and see what the underlying software is. You can try running your custom software on another server with the latest versions if it's outdated. If that doesn't work, then you know you have an issue. It all comes down to how severe the problems are and how far you want to go with repairing the situation.

Buried Under a Mountain of Technical Debt

Sometimes it's hard to know, as an end user, how technical debt affects your ability to use the software. But over time, all projects develop technical debt. For those who don't know, the best way to define technical debt is to reference some of the cartoons you might have grown up with. When a cartoon character falls down a snowy hill, it becomes a snowball, which gets larger and larger as it falls, ultimately culminating in a crash and a snowy mess… that's a pretty good description of technical debt. Over time, technical debt adds up, affecting performance and stability.

As I said, it isn't always easy for an end user to see that what they're working on is layered in technical debt. Sometimes, there may be signs. For example, you may see options in the user interface that are not functioning. Typically, when users walk us through existing software, these areas are met with a shrug or the classic line: "yeah, I'm not sure what that does."

Other indicators that you may be suffering from technical debt could be occasional slowdowns in performance, sometimes due to rogue processes running in the background, or downtime, which is the result of code interfering with itself and driving the CPU crazy.

At some point, it becomes unrealistic to clear out all of this technical debt and continue using what you already have. It's at this point that redevelopment becomes a possibility that you need to consider.

User Frustration

Sometimes, user frustration is reason enough to consider if your software is near the end of its usable life. It isn't typical that frustration alone drives a company to rebuild something. But frequently, the solution to user frustration is improvements to the user interface or user experience. It isn't often easy for old software to receive a new UI UX.

Because of this, it's not unusual for a company to decide it's time to rebuild an entire platform simply because it's challenging to use. A clunky look and feel often can make management think that what's under the hood is a mess too. And that could be the case. A bad user experience is a justifiable reason to consider redevelopment, especially if the software is essential to running the business. For that reason, this should be viewed as a primary factor in determining whether or not something needs to be rebuilt.

It Hasn't Evolved With the Business

If your software is quite a few years old, it's almost a certainty that your business has changed while it's been in service. The question is, has the software been updated as you change how you do your day-to-day tasks? More often than not, the answer is no.

When software doesn't change with the business, the business has to work around it. And this can introduce flawed processes and a lack of organization. The more your business changes, and the less you've adapted software, the more likely you will be stuck and need some major revision.

Much like user frustration, this need not be a reason to rebuild everything from scratch completely. However, it is frequently enough to start the process of solving problems, only to determine that the solutions will take as much time and budget as simply doing a rebuild.

Concluding

There's no single sign or indicator that your software is no longer working for you. It's usually a collection of multiple issues, but more likely than not, one or two of these significant factors that lead to redevelopment are the items I mentioned above.

One last takeaway that I'll add to this post is that the reasons driving you to consider a redevelopment project need to be a primary focus in the planning and discovery process as you architect what the new software will do. You will not be coming into the project as an inexperienced party. You've already been through the development of custom software and have used it for many years. The main goals of a redevelopment project are to build a platform with longevity in mind that solves the problems that led to the redevelopment.

Whether you plan yourself or higher a software architect to assist you, success with your redevelopment project will be combining your experience using custom software with the developer's expertise with these types of projects.

I encourage you to look at the above points and consider which apply to your situation, determining how they became an issue and how you can best correct it as you move forward. This is an easy step to begin with and a good foundation for success with your project.