This week we talk about Software Quality vs Grade.
Definition of Quality
- 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.
Definition of Grade
- 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
How does this Apply to Software?
Softare Quality (in terms of meeting requirements) is a pass fail
Compare to Chemical Engineering
- 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.
Stop Conflating the Source Code with the Product
- 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
Two sets of Requirements
- Software Product Requirements
- Software Process Requirements
- 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…
- Choose to leave a software process requirement unfullfilled, in order to fulfill a product requirement more quickly, cheaply, etc
- 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.
“Tempting Time” by Animals As Leaders used with permissions – All Rights Reserved
An International Speaker, Author, and Microsoft MVP, John has been a professional developer since 1999. He has focused primarily on web technologies and currently focuses on C# and .NET Core in Azure. Clean code and professionalism are particularly important to him, as well as mentoring and teaching others what he has learned along the way.