Other reasons why you should focus on software quality, see attachments.

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.

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

Herewith the source from code bases, see attachment information is beautiful.

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. 

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

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, see attachments.

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.

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

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. 

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

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.

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.

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.

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

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 attachments.

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.

Is you system loosely coupled or tightly integrated? Watch this video and find out what is means and how it can be measured.

Component balance is closely related to your system architecture, hence I'll provide you with additional architectural best practices from Martin Fowler. 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. 

Herewith a nice read (blog post) on large scale example of an Angular application, see attachment.
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 (3) 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.     

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).

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

There are software quality maturity models, although it is not really concrete, see attachment.

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

See attachment for powerful tools!

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

See attachments

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

See attachment (same as previous video)

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

Which additional questions can also be answered by looking at software. A tip of the iceberg: Software forensics is the science of analyzing software source code or binary code to determine whether intellectual property infringement or theft occurred.

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.

If you liked this course, I'm pretty sure you will also like my other courses, consider: Social Engineering: 13 Social Engineering attacks explained! Please find it on Udemy!

Elevate your software development journey with my Software Quality course, where you'll gain the knowledge and skills to create lasting software. Discover the secrets that will enhance your software architecture, design, debugging, and refactoring practices, ensuring a positive impact on your development process.