“What household and software development have in common.”

Building a house is no easy task. You have to reconcile conflicting requirements and at the same time meet completion deadlines and existing cost limits. Decisions that you make in planning will have an effect on comfort and value retention over decades.

The situation looks quite similar for larger software projects. It is necessary to specify and limit requirements because the budget is tight and the time to commissioning tends to be too short.

A blatant difference is also clear when comparing house building and software development:

While those responsible for building a house are subject to many legal norms, local building regulations and full liability for errors, software projects are blindfold tested for their code quality. When accepting such systems, the receiver often only superficially tests performance, load behavior and functionality according to the technical requirements. He forgets that the internal code quality is an essential factor for the preservation of software value. Only if the source code is well-structured and of high quality right from the start, additional requirements can be easily and safely integrated retrospectively. High internal quality thus extends the life cycle of a software. By contrast, software of poor code quality is short-lived as it quickly reaches the point of being unpredictable. In addition, inferior software is a cost driver, as any technical change leads to immense effort in implementation and testing.

Although no one would have a house built without standards, building codes and profound control of the work, software projects are usually handled without or with very weak specifications of the internal code quality. Liabilities concern, if any, only the functional requirements. Since there are no standards or legal standards for most areas of software development, this approach is completely legal from a legal point of view, but extremely fatal from the customer’s point of view.

Can the client himself measure the internal code quality? He can. Fortunately, there is very good support from the open source community:

Sonar (sonarqube.org) is an extremely powerful tool for quality assurance in software projects. Recorded in the continuous integration process, sonar leaks, ie incorrect codes, can be detected early. In addition to static code analysis, it offers the ability to measure the test coverage, to estimate the effort required to remedy quality deficiencies, etc., using plug-ins. Objective quality metrics can be derived from the analysis and must be adhered to. Consequently, these criteria should also be a necessary condition for acceptance by the customer.

The full benefit of Sonar comes in combination with a Continuous Integration Server such as Jenkins (jenkins-ci.org). Build, test and sonar analysis can be automated and create quality reports and sent by e-mail.

Analogous to building a house, this means that you can check with the said setup at every stage of construction, whether the valid standards are met.

Conclusion: Do not rely only on functional tests in the acceptance of software projects! Pay attention to transparency and do not be fooled by colorful icons and animate user interfaces, but go with Sonar under the surface. Check the quality of the delivered work before it is too late. A quality-oriented supplier will always support you.