Refactoring: 8 Software Design KPIs for absolute beginners!

Why software is eating the world by Marc Andreessen: https://a16z.com/2011/08/20/why-software-is-eating-the-world/
Executive management needs to understand that every organisation is becoming a technology organisation. Even if you don't develop IT in-house you'll need to be able to ask the right questions to understand that risks associated with IT. This course will help you understanding software engineering from a bird's eye perspective.     

How 'healthy' are your software system? How would you assess that? This course teaches you 8 essential KPI's that collectively monitor the health of your system. If you companies runs on software, it probably does, you should follow this course. Even when you don't develop or maintain the software, you should follow this course. This because, by the end of this course you'll have a SWISS army knife in your toolkit that enable you to ask the right technical questions to your software vendor. Nowadays CEO's recognise the importance of software for their company:

- https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-reality-of-growth-in-the-software-industry#
- https://www.ing.com/Newsroom/News/We-want-to-be-a-tech-company-with-a-banking-license-Ralph-Hamers.htm

The question remains whether your organisation recognises this movement. This is great news for software managers, software architects and software testers.

Please find a paper written by Google-ers with a title that explains why you are following this course: What Improves Developer Productivity at Google? Code Quality

Poor software quality lead to extra costs for your organisation. This is because poor software quality leads to: more defects in production (which leads to damage of reputation), slower time-to-market (because the velocity in which new functionality can be release tends to decline over time) and lower develop morale (as a consequence talented developers will leave your organisation). 

Software quality assurance staff know how crucial software quality is and thus inherently know why poor software needs to be prevented. Your organisation  can benefit from the 8 software quality metrics explained in this course. These metrics serve as key performance indicators that provide insight into the health of the system.   

Software Is Eating The World, But Services Are Eating Software by Peter Bendor-Samuel: https://www.forbes.com/sites/peterbendorsamuel/2019/10/14/software-is-eating-the-world-but-services-is-eating-software/#2b88c6f32116   

CONSORTIUM FOR INFORMATION & SOFTWARE QUALITY: 'For the year 2020, we determined the total Cost of Poor Software Quality (CPSQ) in the US is $2.08 trillion (T).' (see: CPSQ-2020-Software-Report.pdf attached).

Funny behaviour of developers; it starts with at joke. At some point no one really understand the joke and you're left with legacy code.

ENJOY the FREE Recourses:

- Access to slides (Software Quality for Managers v1.0.pdf)
- Access to eBook (Software Quality - Security Repo.pdf)
- Access to online resources to scan the security of your web application (Additional resources URLs).

By the end of this course you'll have a clear understanding how you can measure and evaluate software systems. If you abstract these metrics you could even evaluate your entire IT-landscape. By doing so you can identify risks early and prevent 'spaghetti' complexity (i.e. systems are inextricably connected which results in low agility).

Even though most managers have a gut feeling about which systems are causing most trouble, managers rarely open the black box. Consider this analogy whit a car. A garage checks the quality of your car (e.g.) yearly. You know upfront which parts need to be replaced and can make a reasonably well-informed risk reward investment decision. Now let us switch back to software system. Can you as a (e.g.) product owner make a reasonably well-informed risk reward investment decision?       

The delivery of software could be seen as a combination of art and science. The artistic freedom of a developer/engineer is expressed as using any combination of tools & technologies to achieve a SMART goal (measured with scientific precision).

Here with a great resource where art meet science, the Netflix culture deck: https://sergiocaredda.eu/inspiration/asides/netflix-culture-deck. Since this contains many slides, herewith a summary of that slide show: https://www.peterkang.com/netflix-culture-deck-7-slides-to-remember/

Other reasons why you should focus on software quality:
https://www.cigniti.com/blog/software-quality-assurance-qa-importance/
https://intetics.com/blog/why-is-software-quality-important
https://smartbear.com/blog/test-and-monitor/5-reasons-why-software-quality-matters-to-your-bus/
https://www.armedia.com/blog/software-quality-control-important/

Please be cautious when developers / engineers leave too many 'TODO' in the code. This typically means, we will fix this issue later. Nothing is a permanent as a temporary solution. Focus on quality and do things right the first time.

Herewith the source from code bases: https://informationisbeautiful.net/visualizations/million-lines-of-code/

Software architects and managers please note that size is almost always strongly correlated with complexity leading to unmaintainable code. Try to measure size with function points and/or lines of code. Function Point Analysis is an objective and structured technique to measure software size by quantifying its functionality provided to the user, based on the requirements and logical design. Lines of code will be explained as the first software quality metric.

Don't be distracted be religious discussion of which method is better, use what best fits your organisation and provides the best results. That could also mean using both techniques. 

Last but certainly not least; don't focus on (a) metric(s) in isolation. Remember that metrics are proxies of an underlying 'bigger' problem. For instance, if code grows in complexity fast it might be because managers set unrealistic deadlines. 

Please note: this question stretches what is mentioned in the video, but we believe it is important to understand these concepts. 

If you don't measure technical debt, you don't know what the amount of deferred maintenance is. This could result in a rude awakening where you'll have to make a surgical procedure into your IT system/landscape. I can tell you from experience, you don't want this! It will result in (1) increased chance of errors in production, (2) lots of stress of your employees and (3) lots of revenue for external consultants, since you'll have to pay them to help you with the surgical procedure.

More background on technical debt:

https://www.productplan.com/glossary/technical-debt/
https://dzone.com/articles/what-technical-debt-it-and-how-to-calculate-it

Academic resources:

- An Empirical Model of Technical Debt and Interest. In this paper, the notions of technical debt and interest have been defined and put into the perspective of IT management. Furthermore, an approach to estimate the amount of technical debt and its interest has been defined.
-Technical Debt: From Metaphor to Theory and Practice. Provides in-depth explanation of the term technical debt.
- The Danger of Architectural Technical Debt: Contagious Debt and Vicious Circles. This article investigated which Technical Debt items generate more effort and how this effort is manifested during software development. This paper presents a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritisation, for further investigation and as a quality model for extracting more precise and context-specific metrics.
- Measure It? Manage It? Ignore It? Software Practitioners and Technical Debt. This study surveyed 1,831 participants, primarily software engineers and architects working in long-lived, software-intensive projects from three large organisations. Developers perceive management as unaware of technical debt issues, and they desire standard practices and tools to manage technical debt that do not currently exist. You Are following this course and are thus aware and now know how to combat technical debt.

Learning software quality through an analogy makes it easy to transfer technical complex subjets to students without a technical background. Especially, for this course, which is geared toward managers, understanding the concepts is important. 

Other relevant books about software that can be found on Amazon are:

For managers:
DevOps Handbook: https://amzn.to/3m3IHjs
The Phoenix project: https://amzn.to/3xOoLmJ
The Unicorn project: https://amzn.to/3fZ0QL5
Lean Enterprise: https://amzn.to/3AVlTqj
No Rules Rules - Culture of reinvention (Netflix): https://amzn.to/2UhEQUl
Securing Devops: https://amzn.to/3AyxwmK

For developers:
Software Engineering at google: https://amzn.to/2LhcaGl
Clean Architecture: https://amzn.to/2Ug6IYS
Refactoring: https://amzn.to/3iGJ2Gt
Clean code: https://amzn.to/3AFKBL1
Clear Agile: https://amzn.to/3xOoLmJ
Design Patterns: https://amzn.to/3jT5hZa
Monolith to Mircoservice: https://amzn.to/37WwWmF
Site Reliability Engineering at Google: https://amzn.to/3sorYII
Building Secure and Reliable Systemen at Google: https://amzn.to/3yYKHNa
Chaos Engineering (from Netflix): https://amzn.to/37E2WvA
Continuous Delivery: https://amzn.to/31IivQw

In this video I compare software engineering with writing a document in Microsoft Word. The document at hand is a part of my thesis. Several elements of my thesis are compared: table of content, chapters, sections and paragraphs. At the end of this video I also map these elements on elements of a software system and you understand the prerequisites for this course!   

Source lines of code (SLOC) is a useful metric in Software Estimation, however relying on it in isolation is dangerous. Always use multiple metrics such that the system can be examined holistically. 

Resources:
- In-depth Analysis of SLOC Metric for the purpose to expose some of its disadvantages and provide knowledge of SLOC Metric Measurement.
- The relationships between Lines of Code (LOC) and defects (including both pre-release and post-release defects)

This information is useful for software tester, software managers, software developers, software engineers.

Tests knowledge gained from the video but also beyond.

Duplication can become a problem within large software systems if programmers make modifications by copying and pasting sections of code. It has long been known that copying can make the code larger, more complex, and more difficult to maintain. In particular, when a bug has been found in one copy, that bug must also be fixed in other copies. If you forget one copy you may introduce another bug or even worse a vulnerability.

Resources:
- Finding duplication in large software systems. This paper focuses on locating duplication or near- duplication in a large software system as an aid in maintenance and reengineering
- Improved Tool Support for the Investigation of Duplication in Software. The goal of this paper is to describe the criteria for a complete tool that is designed to aid in the comprehension of cloning within a software system. Furthermore, this paper presents a prototype of such a tool and demonstrates the value of its features through a case study on the Apache httpd web server.
- Insights into System–Wide Code Duplication. In this paper the authors propose a number of visualizations of duplicated source elements that support reengineers in answering questions, e.g., which parts of the system are connected by copied code or which parts of the system are copied the most.
- The Danger of Architectural Technical Debt: Contagious Debt and Vicious Circles

This information is useful for software tester, software managers, software developers, software engineers.

Select the BEST answer

Unit size refers to the smallest testable part of a program. It is usually a function, method, or class that performs a specific task and has defined inputs and outputs.

Measuring the unit size is important because it helps in assessing the complexity and quality of the code. Smaller unit sizes generally result in code that is easier to read, understand, and maintain. They also facilitate modular design, code reuse, and testing.

Moreover, measuring unit size is a key part of the process of software testing and debugging. It helps in identifying errors, verifying the correctness of the code, and reducing the likelihood of introducing new bugs or errors during the development process.

In general, smaller unit sizes are better than larger ones, as they make it easier to reason about the code and reduce the likelihood of introducing errors. However, there is no one-size-fits-all approach to unit size, and the appropriate unit size will depend on the specific requirements of the software project and the programming language used.

Choose the BEST answer

Every quality assurance / software tester knows the impact of complexity. They inherently know that more paths through the code (i.e. IF, AND, OR-statements) leads to code that is more difficult to understand and test. Couple complex code with no automated tests and a large code base (e.g. more 1.000.000 lines of code) and you have a recipe of disaster. Solution: actively measure and monitor software complexity. 

Off-topic: Did you know that complex code also leads to more security vulnerabilities? See attachment: ON THE RELATIONSHIP BETWEEN SOFTWARE COMPLEXITY AND SECURITY.pdf

For more background knowledge visit:
- https://en.wikipedia.org/wiki/Cyclomatic_complexity

True or false?

Choose the BEST answer

API's expose your system's functionality to users or other systems. It is very difficult to create a clear and secure API. Continuously measure and improve your API.

For more general API content, herewith several links:

Enterprise Integration Using REST: https://www.martinfowler.com/articles/enterpriseREST.html
Lots of resources: https://www.programmableweb.com/api-university
API design: https://www.martinfowler.com/tags/API%20design.html
REST API design: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling

Note that this is not a security course but I always recommend to include security requirements through out your entire software development lifecycle. More information regarding building secure API's can be found in the attachments.

Choose the BEST answer.

Is you system loosely coupled or tightly integrated? Watch this video and find out what is means and how it can be measured. Additional information on God classes / objects: https://en.wikipedia.org/wiki/God_object

True or false

Choose the BEST answer

Component balance is closely related to your system architecture, hence I'll provide you with additional architectural best practices from Martin Fowler: https://martinfowler.com/architecture/. This video is important for software architects and can also be used as input for designing microservices.

From an enterprise perspective: how do your systems compare to each other in terms of size? Obviously you can also use other system-level metrics (e.g.: unit size, complexity, interfacing, etc.) to compare systems with each other. By doing so you can manage your system / application portfolio and get insight into enterprise-level technical debt. 

Choose the BEST answer

Herewith a nice read (blog post) on large scale example of an Angular application: 
https://medium.com/@krposlek/anatomy-of-a-large-angular-application-f098e5e36994
This video is important for software architects and can also be used as input for designing microservices.

From an enterprise perspective: which systems are closely coupled together? By answering this question you can infer information about the agility of your IT-landscape. If several seemingly independent systems have (1) code-level references, (2) follow the same deployment / release cycle and (2) have the same team members or management, chances are that these systems are tightly coupled. Which is not a bad when it is a conscious decision.     

Choose the BEST answer

This video is created for IT (contract) managers that are in charge of managing contracts with suppliers. Ask and demand software quality from your supplier. Make quality an explicit part of your contract with internal or external suppliers. Remember you cannot manager what you don't measure.   

EXTRA:
- In the resources you can find a paper that describes different kinds of technical debt (figure 8) and the cause and effects of technical debt (figure 9) and how to prevent technical debt (table 15).

There are software quality maturity models, although it is not really concrete: http://qualilogy.com/en/software-quality-maturity-model-technical-debt/

Herewith another helpful presentation from Martin Fowler (author of Refactoring): https://www.martinfowler.com/articles/workflowsOfRefactoring/#final
More in practical: Working Effectively with Legacy Code: https://amzn.to/33rwbiN

Quickly identify security depth in webapplications:
https://observatory.mozilla.org/