Let’s be honest: When it comes to software quality assurance, many managers think “Sorry before save!”

Jan 7, 2013 | CIO Knowledge

In these turbulent times the old salesman saying “You are always as good as your last quarter” is almost true for every employee. No wonder, if the deadline is close, developer focus on what provides immediate value to the company: Functions and features. Software quality and the necessary software quality assurance come second.
 

Features instead of software quality assurance

Quality awareness among developers is usually strong. Actually, they would like to deliver high-quality code, but this is often not possible because the management does not allow sufficient time for it. The management often sees only the features (such as a new button in the window) and rewards those developers who present as many functions as possible within a short time.

By this logic, the programmer who can show four instead of one ‘new’ button in the team meeting after a week is better. But what the local management often disregards is the quality of the software, how tested and stable is the program code.
 

Software quality assurance should be incorporated from the beginning

The abstract, “invisible” nature of software makes it difficult for the manager to distinguish low-quality from high quality code. Since bugs and malfunctions occur only over time, often only when the software is at beta customers. But it is expensive to discover and correct errors at this late date. Often the code of the supposed fast developer needs to be refactored. The project plans inevitably run out of control.

Software managers should make sure from the beginning that software quality is incorporated in the internal incentive and reward systems. That means: A developer is only good if he implemented many features in a short time AND if these features are of high quality and tested well. To ensure this, transparency is very important. Both the management and the developers need to see at any time, whether the solutions were programmed clean or sloppy.
 

This is how seereneTM facilitate software quality assurance

This knowledge can be obtained by visualizing the entire code in the form of software maps which seereneTM provides. If the development manager sees a red, vulnerable high-rise building on such a software, he knows that the function was built, but the developer is far from finished. Now the developer has to refine the program section until it is a blue house that stands firmly on the ground and fits into the entire infrastructure.

Of course, this approach means that developing is a little slower at the beginning of the software projects. But that’s intentional. At the beginning of the second half of the project it pays off this residue. Projects remain on track and are often faster than thought.

Pin It on Pinterest