On Measuring Software Design

<div class="cs-rating pd-rating" id="pd_rating_holder_1819065_post_2250"></div> <p class="wp-block-paragraph">Good design leads to good engineering quality and products that are useful, fun to use, simple, efficient and safe. But what is a good design? Is it purely subjective and opinionated or are there specific attributes of a design that lend themselves to introspection and measurement?</p> <h3 class="wp-block-heading">Why measure?</h3> <p class="wp-block-paragraph">Measuring helps us <strong>quantify</strong> something at a point in time. Measuring a design should let us quantify design quality against the key challenges we want to solve with that design. Quite a few design quality assessments evaluate against attributes such as usability, accessibility, safety and event maintainability to validate a design or even compare and select from a pool of design choices</p> <h3 class="wp-block-heading"><strong>Continuous Measurement</strong></h3> <p class="wp-block-paragraph">Measuring and evaluating something regularly gives us a view of change-over-time so that we can do interesting things like look for trends so that we can evolve and adapt better. Regular / continuous evaluation of software design especially for integrated software is a good practice as it provides insight into trends related to the design inputs and constraints leading to proactive change vs reactive change.</p> <p class="wp-block-paragraph">For example, regular reviews can reveal a rapidly changing ecosystem (number of users, volume of data, responsiveness of dependent services etc) so that the design can be tweaked to meet the new demands and adapt the software in a proactive manner. Doing this from errors or customer complaint tickets etc would be reactive and provides a negative customer experience</p> <h3 class="wp-block-heading">Attributes to measure</h3> <p class="wp-block-paragraph">Given the desire to measure design, I started with personal experience and noted down what I looked for in a good design. My initial list took shape as I put myself into a product owner’s shoes and thought about software products in the long term. Here is my list as I noted them down over the years</p> <ol class="wp-block-list"><li><strong>Functional</strong>: Does what it was asked to do</li><li><strong>Accessible</strong>: Users or systems can access it and use it without requiring additional tools</li><li><strong>Reliable</strong>: Do what it needs to do continuously and predictably</li><li><strong>Reasonable</strong> <strong>Resource</strong> <strong>Usage</strong>: Achieves outcome desired using reasonable amount of resources</li><li><strong>Simple</strong> <strong>to</strong> <strong>Understand</strong>: Design is simple to comprehend without requiring additional details</li><li><strong>Unequivocal</strong>: There is no ambiguity so that the design is interpreted differently in changing context</li><li><strong>Safe</strong>: Does no harm to the consumer or provider or others in the ecosystem</li><li><strong>Sustainable</strong>: Does not cause long term to its eco-system such that it is strategically viable</li><li><strong>Implementable</strong>: The resources and materials we have can be used to implement this design in reasonable amount of time </li><li><strong>Maintainable and Operable</strong>: The solution from design is easy to operate and maintain</li><li><strong>Interoperable</strong>: This is key for distributed software as we want faster integration and interoperability is key to good interface design</li></ol> <p class="wp-block-paragraph"><strong>What about industry standards?</strong> Well ISO/SEC 25010 [1] is the standard for Software Product Quality and <a href="https://iso25000.com/index.php/en/iso-25000-standards/iso-25010">this site provides details into the standard</a> </p> <figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2022/03/screen-shot-2022-03-10-at-1.06.20-pm.png"><img src="https://alok-mishra.com/wp-content/uploads/2022/03/screen-shot-2022-03-10-at-1.06.20-pm.png?w=1024&quot; alt="" class="wp-image-2360" /></a><figcaption>Source: <a href="https://iso25000.com/index.php/en/iso-25000-standards/iso-25010">ISO/SEC 25010</a> </figcaption></figure> <p class="wp-block-paragraph"><strong>Process of measuring</strong></p> <p class="wp-block-paragraph">The <em>how</em> in the process of measuring can be achieved through self-introspection post design or through open channels such as <em>assessment via “pull-request’</em> (you version control your design right?) or internal <em>surveys</em> or in some cases committees </p> <p class="wp-block-paragraph">The pull-request (PR) and survey process is great because it helps us to socialise the design with the team (engineering, operations, business analysts etc) and seeks inputs to evolve early. We just need to be careful and time-box the exercise </p> <div class="wp-block-image size-large"> <figure class="aligncenter is-resized"><a href="https://alok-mishra.com/wp-content/uploads/2022/03/screen-shot-2022-03-10-at-1.53.57-pm.png"><img src="https://alok-mishra.com/wp-content/uploads/2022/03/screen-shot-2022-03-10-at-1.53.57-pm.png?w=1024&quot; alt="" class="wp-image-2366" width="621" height="366" /></a><figcaption>Measuring attributes using a survey</figcaption></figure> </div> <p class="wp-block-paragraph">Formal committees can use formats such as this which describes the design attributes against program complexity (see [2])</p> <div class="wp-block-image size-large"> <figure class="aligncenter"><a href="https://alok-mishra.com/wp-content/uploads/2022/03/screen-shot-2022-03-10-at-1.26.02-pm.png"><img src="https://alok-mishra.com/wp-content/uploads/2022/03/screen-shot-2022-03-10-at-1.26.02-pm.png?w=1024&quot; alt="" class="wp-image-2364" /></a><figcaption><a href="https://moodle.polymtl.ca/pluginfile.php/517017/mod_resource/content/1/measurement_software_design_quality.pdf&quot; target="_blank" rel="noreferrer noopener">Design attributes such as Cohesion, Complexity, Coupling </a></figcaption></figure> </div> <h3 class="has-small-font-size wp-block-heading">Measure the constraints and environment with the design </h3> <p class="wp-block-paragraph">The attributes above only consider the design<strong><em> but not the problem itself</em></strong>. If we want to keep a snapshot of our needs over time and then compared the design to this then could we perhaps paint a more accurate picture of the evolving ecosystem?</p> <figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2022/03/screen-shot-2022-03-10-at-2.24.14-pm.png"><img src="https://alok-mishra.com/wp-content/uploads/2022/03/screen-shot-2022-03-10-at-2.24.14-pm.png?w=1024&quot; alt="" class="wp-image-2369" /></a><figcaption>Source: https://ausemergencyservices.com.au/</figcaption></figure&gt; <p class="wp-block-paragraph">Measuring the environment is key when design remains static to proactively evaluate for potential opportunities or threats</p> <h2 class="wp-block-heading">Summary</h2> <p class="wp-block-paragraph">Measuring design is possible if you can start with a set of functional and non-functional attributes and score your design for it. Measuring continuously and measuring the ambient environment is key to knowing efficacy of good design</p> <p class="wp-block-paragraph">We have not talked about measuring Distributed systems designs as these contain inherent complexity due to the graph of connections, the operations per connection (commands, queries and events), the sent/received attributes and the data-mapping</p> <p class="wp-block-paragraph">In a future post we will cover measuring distributed systems design</p> <h2 class="wp-block-heading">References</h2> <p class="wp-block-paragraph">[1] <a href="https://iso25000.com/index.php/en/iso-25000-standards/iso-25010">ISO/SEC 25010</a> </p> <p class="wp-block-paragraph">[2] <a href="https://moodle.polymtl.ca/pluginfile.php/517017/mod_resource/content/1/measurement_software_design_quality.pdf">“The measurement of Software Design Quality” – James K. Blundell et al</a></p> <p class="wp-block-paragraph">[3] https://link.springer.com/article/10.1023/A:1018914711050</p&gt; <p class="wp-block-paragraph">[4] Liskov, B. and Guttag, J., “Program Development in Java: Abstraction,<br>Specification and Object-Oriented Design”, 2000, Addison-Wesley.</p> <p class="wp-block-paragraph">[5] van Vliet, H. “Software Engineering: Principles and Practice (2nd Edition)”<br>Wiley, 1999</p> <p class="wp-block-paragraph">[6] Budgen, D. “Software Design”, 1994</p> <p class="wp-block-paragraph">[7] Pirsig, R. M., “Zen and the Art of Motorcycle Maintenance : An Inquiry<br>into Values”, 1974, William Morrow & Company</p>