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:
| factor | impact in the project |
|---|---|
| Static analysis in advance | Quick quality assessment even without a running system |
| Agile mindset | Adapt plan and team setup on the go if new gaps emerge |
| Rehearse migration several times | Find sources of error before the real thing, five minutes of real cutover |
| Open communication | Put problems on the table early, actively force decisions |
| Customer commitment | Joint Scrum course reduces frictional losses |
| Full-time testing | Structural guidelines instead of saving in the wrong place |
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.
Frequently Asked Questions
What can static code analysis accomplish when no executable system is available?
It provides insights into maintainability, robustness, and security without requiring the software to run. In the ticket shop project described, only one and a half days were available for the initial assessment—not enough time for a full manual review of several thousand lines of code. Tools like SonarQube covered the provided portion of the code, supplemented by a manual review. That’s sufficient for an assessment with concrete recommendations.
What risks are associated with purchasing existing software?
It’s usually not the code itself that’s the biggest hurdle, but rather what’s missing. In the case described, the code that was reviewed was well-written, with no serious defects. The problems lay in the gaps around it: documentation below professional standards, components that were delivered late due to shifting responsibilities, and one-third of the software that was available only as a compiled version without source code.
What are the benefits of testing a migration in advance with real live data?
The dry run uncovers sources of error before they strike in a real-world scenario. Three weeks before the deadline, the migration was fully tested and prepared using all live data. The actual cutover then took five minutes, after which the system was up and running. The rule of thumb behind this is: plan twice, execute once. For a store with zero tolerance for downtime, this is the decisive factor.
Does the chosen timing affect the risk of a migration?
Yes, and measurably so. A Tuesday at noon was chosen for the ticket shop’s cutover—statistically the time with the fewest users. Heat and the vacation season compounded the challenge, as did the chief architect’s absence during the three weeks leading up to it. This was offset by having the second architect and the lead developer run through the process, and then going over everything together again after the lead architect’s return.
Why does the plan almost inevitably change during a software takeover?
Because the analysis takes up more time than expected. The plan had been to perform code analysis, refactoring, implement a few features, fix bugs, and create documentation. In reality, a lot of time went into fully understanding the system and identifying all its components. This led to the question of what the customer really needed in the first phase. The team setup was reorganized: some developers were removed, and a second architect was added.
Is it worth cutting back on testing first when the budget is tight?
No. That doesn’t make a project cheaper; it makes it more complicated and more expensive, because skipping quality assurance only delays problems. A development team needs more than just coding—from requirements engineering to testing—and these disciplines deliver more value than they cost. In the project described, a full-time test manager was on staff instead of the more common part-time role. This provided a strong structural framework for the process.
How do you handle bad news when multiple companies are involved in a project?
Every new finding must be shared immediately with all stakeholders. With four companies involved, the team was convened, scenarios were written down—in one case, four or five—and everyone contributed their assessment. In meetings, the rule was not to leave the room without reaching a decision. Hiding information accomplishes nothing: the problem that was kept secret will surface later, usually at the worst possible moment.
How should a team be structured for the adoption of third-party software?
Diverse from the very beginning, even if the project’s course seems clear. An interdisciplinary team can replace one area of expertise with another as soon as the direction changes. In the case described, app development, various cloud technologies, and expertise in testing, project management, and automation were all present at a comparable level. It was precisely this ability to pivot in the middle of the project that was one of the key factors in its success.
