What Running Your Application Can Tell You About Its Quality?

I mostly work with long-lived applications that undergo continuous modification. Evaluating their quality by simply glancing at the code would be rather naive—there are multiple dimensions to consider for a more comprehensive assessment. Of course, code quality matters, but there are several other checks I perform. Today, I want to share a subset of those checks—focused specifically on application execution—and what insights they can offer.

Can I Run It Locally Without Help?

This is always my first test: I try to run the application locally, entirely on my own. If I succeed, it's usually a good sign that one of two things is true:

• There is existing documentation that clearly walks through the installation, integration, and configuration steps—and it’s up to date.

• The application is simple enough that no documentation is needed to get it running.

Either scenario suggests a healthy developer experience.

Can I Run It Locally Without Internet?

If I can run the application without an internet connection, that tells me a few things:

• The integration points are likely well abstracted, which is a strong indicator of good design—at least in some areas.

• The application might have no external integrations at all. That usually implies it's not a sprawling, overly complex system.

• Everything is self-contained, suggesting a manageable level of complexity and size.

All these are positive signs.

Can I Run It Locally at All?

Sometimes I fail to get it running independently and need to ask for help. If I eventually succeed, that highlights a few potential issues:

• Documentation is either missing, incomplete, or outdated.

• The application might be using internal tools or custom solutions that aren’t widely known or documented.

This adds hidden complexity—something to seriously consider when planning any modernization or refactoring effort.

Is There Anyone Who Can Run It Locally?

There have been cases where, even with help, I couldn’t get the application running. In such situations, I look for someone—anyone—who has managed to run it successfully. If I find them, I try to pair with them and revisit the previous steps.

However, if even a working local example fails to run on another machine, it suggests we’re dealing with some unknown mysteries in the setup. This highlights an unpredictable environment—one that increases the chance of failure during improvements or migration and makes the system harder to trust.

Do We Have a Non-Production Environment Where the Application Runs?

If local execution isn’t possible for anyone, the next best thing is to check for a non-production environment where the application is deployed and running. If one exists, that becomes our playground for exploration and troubleshooting.

In such cases, we can:

• Compare the local and non-prod environments.

• Incrementally mimic the production-like setup locally.

• Learn how the application is built and deployed—especially if it’s rebuilt from scratch each time.

But if no such environment exists, then production becomes our only testing ground—and that’s never a safe place to experiment.

Summary

As you can see, the ability (or inability) to run an application can reveal a great deal about its current quality. The more people you need to involve just to get it running, the more dependencies and hidden risks you're dealing with. Whether the application can be executed at all—locally or in a controlled environment—offers valuable insight into the risks ahead and can help shape your next steps.