I do not discuss XRP explicitly in this post. Rather, I write about quality, specifications, and defects. With basic concepts out of the way, I then propose a high-level, readable specification that serves to address salient aspects of the transfer of value on the Internet of Value (IoV) and as such can be a starting point for developing conformant and defect-free designs. From another angle, such a specification can stand as a manifesto of rights for customers who have too long been subjected to inferior service in the area of transfer of value while being charged premium fees for it.
Defining quality
If we want to achieve a standard of quality, we must first define quality.
Philip B. Crosby (1926 - 2001), one of the most enlightened thinkers and doers of the 20th century in matters of quality, wrote something1 I have often gone back to reread and reflect upon.
I built the Quality College around the Four Absolutes of Quality Management as they had evolved for me over the years (bold emphasis mine):
Quality means conformance to requirements, not goodness.
Quality comes from prevention, not detection.
Quality performance standard is zero defects, not 'acceptable quality levels.'
Quality is measured by the price of non-conformance, not by indices.
Notice that the four points address, concisely and in succession, a definition of quality, a system for quality, a performance standard for quality, and the measurement of quality. I have yet to see something that improves on it.
Mr. Crosby also believed that 'quality is free', meaning that the cost of quality and doing things right the first time would be more than offset by the associated savings generated in being able to avoid rework and repairs.
All that said, we cannot assess the quality of any effort, service, or product while we lack something to judge it against. That something is a specification.
What is a specification?
In the simplest terms, a specification conveys meaningful concepts as to the functionality of a non-existent system or one to be redesigned. A specification tells you what a system is to do. It is not the job of a specification to explain how the system is to do something, this being the province of design and implementation. A specification can be satisfied by a number of designs, so this is not a one-to-one but rather a one-to-many relationship. A specification can be validated against customer requirements and verified for internal consistency. It can also be developed at different levels of abstraction, with no more than the required level of detail at every level. In so doing, it can reduce clutter, always a good thing when thinking about how to solve a problem. Most importantly, a good specification provides a firm contractual basis for the delivery of a service. This is where a well thought out specification can act not only as a technical tool but also as a legal instrument in defense of the customer.
I want to mention very briefly that formal specification occupies an important place in software engineering. Designing real-time systems where a faulty design, incorrect operation, or environmental interaction may cause life to be at risk, means that software programs must be shown to be provably correct, to terminate properly, and, depending on the situation, to be fault-tolerant -- examples come from train signaling, aircraft communications, power plant shutdown sequences, among others.2 Sadly, even today, many commercial developers skip the specification part due to lack of awareness as to the importance of this area or due to having to work under managerial deadlines which mistakenly put the focus on coding tasks at the expense of almost everything else. This is unfortunate, as rising software maintenance costs, testing as an alternative to proof, and lack of reuse of designs can often be traced back to the inattention paid by responsible parties to this fundamental and earliest of phases.
Formal specification
A formal specification is strictly non-algorithmic and closer to the problem domain, and starts from the business end of things, whether one is specifying an entirely new system, an existing one to be refactored, or just safety-critical aspects of either. It uses discrete mathematics and logic and expresses the 'what' aspect of a system in functions and mappings called predicates. It can be algebraic (no explicit model) or model-based and state-oriented.
A design and an implementation, on the other hand, grow closer to the computer domain and as they develop the 'how to' aspect they look increasingly procedural and more and more like pseudo-code. The latter also are derived from a formal specification through reification, meaning that the final product emerges through successive refinements of earlier, less concrete versions. There is a continuity from each phase to the next, and this two-way traceability helps as designs increase in complexity.
A specification can be animated and its behavior studied through the use of specific tools, and its correctness and state-oriented invariance can be tested. What this means is that, to be considered correct, every operation the system undergoes must leave it in a state that is consistent with the previous state and the result of the operation, and nothing else. Once defined and initialized, invariants cannot be violated by correct operations. A proper specification can be verified as to correctness and give confidence that a solid foundation is in place to build on. From yet another viewpoint, a good specification can help prevent scope creep, gold-plating of designs, all too frequent afterthoughts tacked on, and generally avoid delays in delivery.
Afterthought.
I hope I have successfully outlined why specification in general, and formal specification in software engineering, are important. I will leave it at that, as more detail would be out of scope for the purpose of this post.
We now have a concept of what quality means and also what a specification is and can do. Are we ready to discuss a specification for the transfer of value? Almost.
But first, a word about errors and defects
We should try to become aware that differences exist between terms such as error, bug (in software), defect, and failure. Generally, an error is a mistake that can be traced to a human, a bug is what a tester calls an error he/she has detected and documented, a defect is the consequence of an error as realized in the product or service provided, and a failure is an overall inability of a defective product or service to meet the customer's requirements -- what we could call the specification.
These definitions are certainly not set in stone, and companies and standards organizations differ in how they use them. While it is important to be specific when one discusses errors, defects, and failures, and to have clear operational definitions as to each, we will not get into that here beyond this brief mention. On a lighter note, I will also skip discussing the feature label, applied by the facetious to a persistent and documented software bug once it becomes an unofficial part of the next release.
To our grasp of quality and what a specification is, we also have added an understanding of what a defect is. We can now move to the original objective of the post.
Proposed specification for zero-defect transfer of value on the IoV
Here, I would like to propose a high-level specification for zero-defect transfer of value on the IoV. This set of requirements addresses various aspects inherent to this process, as follows:
-
- Value: value shall be transferred in the right amount every time.
-
- Customer: sender and recipient of value shall be identified as the customer, and value shall be transferred from the right sender(s) to the right recipient(s) every time.
-
- Path: value shall be transferred via the most efficient path available between sender and recipient every time.
-
- Time: settlement time shall not be significant in absolute terms and shall be near-simultaneous with payment.
-
- Liquidity: the sourcing of liquidity deemed necessary to effect a transfer of value shall not significantly impact the settlement time or in any negative way impact the cost of said transfer to the customer.
-
- Cost: the cost to be incurred for a transfer of value shall be known to the customer in advance of the same, shall not be significant relative to the value transferred, and shall be entirely reimbursable to the customer for any and all value transfers that fail to meet any requirement of this specification on first pass and that may need to reoccur, for as many times as they need to do so.
-
- Transparency: complete information as to the status of a transfer of value shall be available in real-time to the customer at all times between transfer initiation and completion, without any unilateral action occurring during said transfer which the customer may be unaware of and that has not been explicitly authorized by the customer.
-
- Ownership: ownership of value in transfer shall be retained by the customer at all times, negating the possibility of detention of said value for any length of time by any parties to the transfer, or for any purpose not explicitly authorized previously by the customer, including value conversions between currencies and deployment of value for short-term benefit of any party other than the customer.
Conclusion
Notice that the above high-level specification says nothing about how to achieve the objectives stated. This is as it should be, and does not make the specification vacuous. On the contrary, having such a vehicle, simple as it appears, anchors any design that is to follow by giving it something to be assessed against, and, importantly, in so doing shifts the system of quality toward prevention of defects and away from the more common late detection that is an implicitly accepted part of much software development. The specification may well benefit from additional requirements, the purpose here not being to claim completeness but rather to illustrate an approach.
If something is not in the specification to begin with, it may not end up in the code, or it may get there as a result of expediency or for another practical reason, which will in all likelihood have nothing to do with a a requirement based on a matter of principle. As I said at the beginning, from an additional perspective, this specification can act as a manifesto of rights and contractual framework for customers too long hostage to deficient, grossly over-priced service in the area of transfer of value.
For any design developed from the specification proposed above, each of its characteristics would need to be traced back to one or more requirements of said specification to successfully establish proof of conformance. A design not meeting this high-level specification in its entirety would be considered non-conforming. A design meeting the specification in its entirety in a provable manner could be considered to be conforming in implementing zero-defect transfer of value within the scope of requirements coverage.
And what is more relevant to the rights of the customer than a process of provable quality guaranteeing a zero-defect service or product?
References
- Crosby, Philip B., Quality is Free: The Art of Making Quality Certain, Mentor Books, Jan. 1980.
- O'Regan, Gerard, Concise Guide to Formal Methods: Theory, Fundamentals, and Industry Applications, Springer, Aug. 2017.
