The 6 Figure Developer Podcast

Episode 086 – Software Quality vs Grade

Apr 8 '19

This week we talk about Software Quality vs Grade.

PMBOK V.5 – “Quality is the degree to which a set of inherent characteristics fulfills requirements”
- PMBOK: Project Management Body of Knowlege
ISO 9000:2015 – “Quality is the totality of features and characteristics of a product or service that bear on its ablility to satisfy stated or implied needs.”
- ISO: International Standards Organization (International Organization for Standardization)
Put Simply – Quality is the fulfillment of the requirements.

PMBOK V.5 – “Grade is a category or rank used to distinguish items that have the same functional use but do not share the same requirements for quality.”
Put Simply – Grade ranks items by the strictests set of requirements they fulfill

Softare Quality (in terms of meeting requirements) is a pass fail

Produced Various Grade’s of Polymers
Any product could be in-spec (within specifications) or out-of-spec(outside specifications) of a given set of requrements
Across Chemical companies, the process for creating production vary significally regardless if they are producing the same grade of product (the end user is generally uneffected)
The processes themselves are measure and can be certified to meet certain specifications.

Software specifcations are (should) be written from the funtionality value that is provided to the user.
Software should be evaluated according to the fullfillment of those requirements.
We cannot ignore the process of creating, maintaining and changing software

Gold plating is simply meeting additional software product requirements that are not in scope
We need to stop gold plating, if the changes are needed there needs to be a change of scope
Gold plating is not following architentual and devleopment choices to ensure proper software process requirements are met
- Where does logging fit in?

Should be only 2 kinds of Techincal Debt but…
- Intentional
  - Choose to leave a software process requirement unfullfilled, in order to fulfill a product requirement more quickly, cheaply, etc
- Discovered
  - Fulfillment and specification of software process requirements, create additional burden in order to fulfill a softare product requirement
- (Unfortunate Third) Unintentional
  - Poor fullilment of software process requirements either because of lack of understanding, specification, or negligence
Tech Debt is a lot like real debt in that it costs interest while it exists
So might choose to take on tech debt to more quickly produce a feature, however, until its “paid off” every new change will cost itself plus the additional interest of the debt
This snoballs when the business does not want to pay the cost+interest of the next feature and looks to use more debt to reduce that cost
Discovered Technical Debt is reduced by following good design patterns and practices, like, SOLID and TDD as they tend to leave the code easier to change.