Software Analysis

Software quality analysis when adopting an unknown code base refers to the structured procedure for evaluating the condition of third-party software in a short period of time. Static analysis tools such as SonarQube provide initial insights into maintainability, robustness and security. Missing documentation and incomplete components are among the most common risks of such takeovers.

Key Takeaways

• Cutting testing from the budget first makes projects more expensive and complicated, not cheaper, because a lack of quality assurance only delays problems, not prevents them.
• A full-time test manager in the development team is unusual, but brings structural clarity that directly relieves all other disciplines.
• Openness about project risks must come early: If you hold back bad news, you will get it back at a less favorable time.
• In concrete terms, an agile mindset means reorganizing the team setup in the middle of the project when the requirements have shifted, for example by appointing a second architect instead of a developer.
• A migration without downtime is more reliable if it is fully rehearsed three weeks in advance with real live data.

Adopting third-party software means expecting surprises

Anyone who buys existing software rarely takes over a cleanly documented package. More often it’s a surprise egg: you don’t know exactly what’s inside, what the quality is like and whether the system is maintainable at all.

This was precisely the situation faced by a public mobility provider when it took over an existing ticket store. It was not just about usage rights, but about the entire product. Before the purchase, it was unclear which components would be included, how good the code was and whether the takeover would be worthwhile.

Sonja Trimmel and Helmut Nitsch accompanied this project. Their experience shows what is important when you take over an unknown code base and bring it to a sustainable state.

How do you evaluate a foreign code base in a short space of time?

An initial assessment is possible even under time pressure if you use static analysis. Only one and a half days were available for the initial assessment, not enough time for a full manual check with several thousand lines of code.

Tools for static analysis, such as SonarQube, provide a useful impression in this situation. They make statements about maintainability, robustness and security aspects without the need for an executable system.

The security view is particularly important for a ticket store. Such a system has a high touchpoint to the outside world and is used frequently. These properties can be easily viewed automatically.

In this case, there was no running system. The ticket store was visible online, only a piece of the code provided was checked, with static analysis and manual review. This is sufficient for an initial assessment in order to derive concrete suggestions.

The code was not the problem, the missing parts were

When adopting software, the biggest hurdle is often not the code, but what is not included. The audited code itself was good, no serious defects.

The gaps around it were more difficult. Due to changing responsibilities, some components arrived late. The documentation was not up to the standard that a professional team would expect.

During the familiarization phase, the real sticking point became apparent: some of the software was only available as a black box, as a compilation without source code. Around two thirds of the software was available in code, one third was not.

This moment marks the point at which a planned takeover turns into a surprise. Suddenly the question arises as to how to continue working with the missing source code.

Why an agile mindset makes the difference in software acquisitions

Anyone taking over unknown software needs the ability to change the plan on the go. The original idea was to analyze the code, refactor it, add some functions, fix bugs and update the documentation.

In fact, the focus shifted. A lot of time went into the analysis because we had to completely understand the system, find all the parts and prepare them for further use. The pure refactoring idea became the question of what the customer really needed in the first step.

The team setup was reorganized accordingly. Instead of continuing with the initial team, some developers were removed and a second architect was brought into the project. A total of five months, two architects and two developers were available.

Helmut Nitsch emphasizes that this is not about agility as a label.

I’m not talking about what you are preached, but about having an agile mindset in order to be able to react flexibly to certain things. That was essential.

• Helmut Nitsch

This flexibility, coupled with the client’s trust, was a success factor on both sides.

How do you plan a migration without downtime?

A migration without permitted downtime is achieved through repeated rehearsals with real data. In the case of a ticket store, the system must not fail; the change must work practically from one moment to the next.

Three weeks before the deadline, the migration was rehearsed with all live data and fully prepared. This dry run uncovers sources of error before they strike in an emergency.

The timing was an additional complication. Due to postponements, the migration took place during the vacation period and the chief architect was absent for the crucial three weeks. A migration in the heat and during the vacation period increases the risk of human error.

The solution lay in the preparation. The second architect and the lead developer rehearsed the migration and prepared everything. When the architect returned, the team went through everything again together.

The date was no coincidence either. A Tuesday lunchtime was chosen, statistically the time with the fewest users in the ticket store. The result: the actual migration took five minutes, after which everything was up and running.

The underestimated factors on migration day

In addition to technology and planning, it’s the soft factors that count. On migration day, all the developers sat in an air-conditioned room, early at the start, with food and drink provided.

Catering and atmosphere are not a minor matter. Providing a good working environment on a critical day reduces stress and therefore the likelihood of errors. The rule of thumb behind this is simple: plan twice, do once.

Honesty and communication carry the project

As soon as surprises arise, communication determines the outcome. Four companies were involved in the project, so close coordination was necessary.

The procedure was consistent: every new finding was immediately reported to all those involved. The team was called together, scenarios were written down, in one case four or five, and everyone contributed their assessment.

Decisions were actively enforced. In meetings, the rule was not to leave the room until a decision had been made, because delay only costs money. Tough prioritization is part of this.

The most critical phase came almost at the beginning. Missing documentation, undelivered code and the realization that the time and budget were not going to work out, brought real pressure, especially as other projects were hanging on.

In this situation, only openness helped. Instead of hiding problems, the scenarios were laid openly on the table: this approach will get you here, that approach will get you there, and only this approach will get you to the end. Hiding information is useless, because the concealed problem emerges later, usually at the most inopportune moment.

Customer commitment is more than budget

A strong commitment on the part of the client is demonstrated by the fact that he prepares the entire team to speak a common language. Before the project started, the client sent the entire team on a Scrum course.

The aim was not just to impart knowledge, but to ensure smooth communication. If everyone involved understands the same terms, there is no friction when coordinating.

The effect was noticeable. When the team said something, the other side knew exactly what was meant. This kind of commitment is very different from the widespread pattern where the customer says “go ahead” and only provides support with a few part-time employees.

When saving money, the first thing to be cut is testing, and that takes its toll

One constant runs through more than twenty years of testing: when savings are made, testing is cut first. This does not make a project cheaper, but more complicated and more expensive.

Development is not just about coding. A development team needs other disciplines, from requirements engineering to testing. These disciplines bring more than they cost and help to bring a project to a successful conclusion.

This project involved a full-time test manager, which is rather unusual in development projects. It is more common to have a half-time testing manager on the side. The full-time position gave the process a lot of structural direction.

What lessons can be learned for the next software takeover?

The most important lesson is: set up a diverse team right from the start, even if you think you know how the project is going. During the project, the team had to be reorganized several times as soon as the direction changed.

An interdisciplinary team can replace one competence with another when the project turns. It was precisely this reorganization that was a success factor. Among other things, app development, various cloud technologies and expertise in testing, project management and automation were bundled at a comparable level.

In practice, the key factors can be summarized as follows:

Adopting third-party software remains a risk. But if you bring together analysis, flexibility, honest communication and a broad-based team, you can turn even a surprise egg into a viable product.