Author: Niels Doesburg

The risk of in-house software construction

The risk of in-house software construction
A lot of software is developed in the business world, some of which concerns in-house software construction. In-house development teams may run the risk of an imbalance of attention distribution between functional and structural quality during the construction of the software. How can the risk of this be limited?

In-house software construction
From the 1970s onwards, an important part of IT support for business processes was based on the use of standard software packages. Nowadays, the use of software packages is no longer self-evident, and having software built is a realistic option for many companies. The “build-or-buy” choice that management has to make to support business processes is more often than before in favor of “build”, having the software built. There are very various reasons for this. Consider the decreasing costs of the necessary infrastructure for software construction, the improved transferability of the management of custom software, the growing number of software-driven business models and the higher expectations of consumers with regard to flexibility in the process.

Some companies are going even further on the “build” path. They not only choose to have the necessary software built, but choose to build it in-house, despite the fact that software building is not their primary process. The organization itself puts together a team, consisting of people from inside and outside the organization.

The difference between functional quality and structural quality
The quality of software consists of two aspects, namely the functional quality and the structural quality. The functional quality is the degree to which the software meets the functional specifications and criteria. Does the software do what the users need?
The structural quality is the way in which the software is constructed. Is the structure logical, scalable, easy to adjust and analyze? There is a risk that structural quality will receive insufficient attention in an in-house development team.

Risk of unbalanced attention distribution
The build-up of the in-house development team and the context of the organization can cause the team to lose sight of the structural aspect of software quality. Here are some examples that could cause such an imbalance:

The Product Owner and budget holder of the in-house development team knows the business very well, and can assess the interests very well, but usually has no background in software construction. The developers must therefore be able to communicate very well and be very strong in their shoes to explain why certain choices with regard to structural quality are better than others.

When the urge to prove in the team is high, or when certain developers like to present themselves as smart and fast, a toxic interaction can arise between the Product Owner and the relevant developers, whereby the realization of functionality is rewarded, but where the assurance of a manageable scalable and comprehensible software architecture is lacking.

The organization in which the team operates can place a lot of emphasis on the business cases behind the time division of the developers. But what is the business case of a good error logging infrastructure or a logical modularization? The business case for a solid software architecture is difficult to quantify and mainly consists of the prevention of increasing costs (and not unimportantly: demotivated developers). When the software is built with shortcuts, workarounds and other structural weaknesses, it will take more and more effort over time to understand, monitor, analyze, modify and expand the application.

Typical symptoms of unbalanced attention distribution
The following shortcomings in the software are typical of the lack of sufficient attention to the structural quality of the software:

  • Inadequate error handling so that the user is not aware that his data is corrupted after an error in the code has occurred,
  • Inadequate logging, so that errors that have occurred are difficult to identify and resolve,
    Incomplete authorization implementation, causing some APIs to be open to the entire organization (and perhaps beyond),
  • Inadequate validations on the correctness and completeness of the input by the user,
    State management, the retention of the phase in which the program or the edited object is now, is tracked with separate variables spread by the logic instead of in one central place with predefined scenarios,
  • No modularization but direct connections between all parts of the application,
    No abstractions for parts that may be replaced in the future, but interweaving of these parts with adjacent logic,
  • Inadequate inline documentation,
  • Unclear naming of directories, files, functions and variables, which makes new developers not being able to properly see the code,
  • Inconsistent syntax making reading and understanding the code time consuming

Risk mitigation measures
The measures to limit the risk of an unbalanced distribution of attention between both aspects of software quality within the in-house development team are obvious, but they are not easy to implement:

  • Ensure that all developers have sufficient conceptual thinking, and that sufficient seniority within the team is present.
  • Guarantee team spirit and prevent cock behavior.
  • Ensure a good design of the application and new features, which are supported by the whole team.
  • Ensure that the organization, stakeholders and the Product Owner understand that building software is more than just code, and that software quality consists of two parts: Functional quality and structural quality.

Specific questions?

Enter your e-mail address and Oliver IT will contact you as soon as possible!

Done! We will contact you soon!
Robin Schutten Sales
Robin Schutten