+1 571-297-6383 | info@sonjara.com

How to Evaluate a Code Base

One of the services we offer at Sonjara is the Technology Evaluation. Usually a client has inherited an existing website or application and they need an independent evaluation of what state it is in and what should they do next. Here are all the steps and stages of a technology evaluation of an existing code base.

Step 1: Understand the Project

Before we start the evaluation, we need to know as much as we can about the project, such as

Finally, we also need to know the parameters of the evaluation.

Step 2: Access Existing Code base

Getting copies of whatever information we can gather is important. We try to get the original source code if possible, a copy of the database schema and at least a sample data set. in some cases, we cannot get the source code, so we may have to run the code through a decompiler and then reconstruct it into a development environment. Ideally, we would also have access to the production server, at least to see if there are any special configurations with the server we need to be made aware of.

Step 3: Determine Architecture

Once we have a good sense of what the site should do, and currently does, and we have a copy of the code base, we look at the documentation and code base to determine the software architecture method. What does the data model look like and how is data managed? Are there common functions?

A subset of this step is to determine the level of site conformance to that architecture. On organically grown sites, or ones managed by multiple development teams, we tend to find discrepancies between the architecture and implementation. The more work arounds put into place, the less the architecture is solidly constructed, and often we find many holes.

We also examine authorship of the code base. While every developer has their own signature in code, a well engineered site should have a level internal consistency despite many developers being involved. Less consistency between developers means that the architecture may have been undermined.

Step 4: Identify the Metrics of Evaluation.

We generally specifically measure the quality of a site based on the following criteria:

Step 5: Determine Recommendation Parameters

Based on Step 1, we should already know what the goals of the evaluation are. We also need to understand what the expectations of the client are for past decisions.

We try very hard to not bias the evaluation by either being too hard or too lenient, and instead base it on the goals of the evaluation. 

There can be a tendency for any developer to dislike another developer's code base because "I wouldn't have done it that way". We also know that best laid plans are thwarted by small budgets, unexpected changes, contradictory client guidance, staff turn over, and the fact that everyone hates to document their code.

We don't expect perfection in code, but rather 'good enough to get it done according to requirements'. Our metrics above are based on our experience of what makes code solid; no-one's code will ever be perfect according to every single metric.

Step 6: Make Recommendations

We start by looking at what is working well according to the goals of the site. These features need to be protected or carried through to the next iteration.

We then find the places where the current structure doesn't meet the requirements (either current or anticipated future ones).

Based on the requirements for the evaluation and for the software, we then rank the gaps based on importance for the client.  For example, for a website that has been inherited by a new team and needs some changes to it, we will focus on recommendations that address immediate needs, with other priorities (about scalability or long term performance) lower on the list.

Our recommendations for changes usually are based on the question of "fix or replace". The recommendation is based on the project lifespan; a project that is winding down and has less than a year left, it makes more sense to fix and make do, than to replace the entire system. On the other hand, a vital element of your company operations that generates revenue? yeah, you may want to replace it from scratch as the expected rewards of a new system (new features, lower maintenance costs, etc) may well outweigh the costs.


Our goal in any of these technology evaluations is to give our clients information on the best next steps for technology they have inherited or own. Getting an independent set of eyes from people who have managed and built hundreds of websites and applications over the past two decades can be invaluable to determine where to put your resources.

« Back to Sonjara Blog