In all engineering business poor quality equates to cost; this is equally true in software systems. Lack of quality inevitably means re-work and expensive scrap (effort), and if it escapes to the customer, we get cost of warranty, customer dissatisfaction, reputation damage as well as the distraction of fixing things in a hurry (which consumes your management and engineering effort).
Conceiving a simple, well-structured product with a clearly defined and understandable architecture will help keep all the engineers working to the same goal, but their individual skill level and experience may differ. As software is not bounded in physical, measurable, materials but is a human endeavour, structural definitions alone are not enough.
Humans make errors, software is made by humans, therefore software will contain errors. Not all errors will be detected, but not all residual errors will manifest as faults, and not all faults will manifest as failures, so a product full of errors may never fail!
An unfortunate issue for software development is that software development automation tools are in themselves software and subject to the same problems.
Most experts agree that for software, processes define product quality, not unlike manufacturing. The choice of rigour (adding more feedback cycles for validating we have the right product, adding more events for verifying we are building the product correctly) determines how many errors we remove and therefore the ‘quality’ of the production item.
The cost of software development is directly related to how quickly (after injection) an error is detected, and the set of processes involved in the round trip of correcting and verifying its removal. If rates of injection were constant then: Less detection steps => errors found later => longer correction process => greater cost of correction. The reality is that rates of injection are not consistent, but are highly dependent on expertise and experience of engineers, but more detection steps => slower development=>more cost of development. However, it is generally accepted that error correction costs increase significantly with error duration before detection.
Early investment in detection and correction is easily wiped out if the system definition is volatile, hence high-rigour systems (e.g. Nuclear, Space, Aero) tend to be less able to accommodate late change without significant impact on cost or timescale; but then we expect these systems to be ‘right first time’ or at least accommodate any faults detected in operation!
The cost of software ownership is directly related to the number of fielded failures, which in turn is related to error escapes, irrespective of their root cause (and system change is the most common). Lightweight processes may save on development costs (and indeed cost of correction) but potentially field more errors/failures.
If the business offers warranties, has service level agreements or maintains a high reputation for robustness, lightweight may not be an appropriate answer, whereas for ‘disposable’ products (e.g. Mobile Apps) or prototypes, lightweight processes are key.
Be warned: Most businesses find it difficult to get their software engineering teams to live different process rigour levels for different phases or products!
___________________________________________________________________________
Let us help you maximise the business potential of your product and its software
Email me on stuart.jobbins@sofintsys.com
Visit our website, or follow us on your preferred Social Media for our latest views. 
___________________________________________________________________________