DevSystemsWiki | Insight Maker

Stock: Bugs: measured by the number of errors or defects in the code)

Balancing Loop 1: Internal quality

When the number of errors in the code increases, the effort dedicated to software maintenance is increased.

This leads to the identification and correction of underlying issues in the software's architecture and design that might be causing recurring errors.

As these underlying issues are addressed, the internal quality of the software improves and the number of errors in the code decreases.

Balancing Loop 2: External quality

When the number of errors in the code increases, the effort dedicated to quality control is increased.

This leads to the identification and correction of errors.

As errors are corrected, the external quality of the software improves and the number of errors in the code decreases.

In this system, both balancing feedback loops compete to improve software quality, but they focus on different aspects of the process (external quality versus internal quality). As errors and underlying issues in the code are addressed and resolved, the internal quality of the software improves, which in turn reduces the amount of effort required for quality control and maintenance. This is similar to the thermostat example, where the two balancing feedback loops work together to maintain a desired temperature.

Internal Quality vs External Quality

Alfredo Artiles

5 months ago

The diagram symbolizes the process and the patience required to fine-tune a product, similarly to adjusting a shower's temperature.

Inspired by Gene Bellinger's Adjusting-the-Shower-SFD

Iterative and Incremental Product Development

Alfredo Artiles

Stock: Bugs: measured by the number of errors or defects in the code)

Balancing Loop 1: Internal quality

When the number of errors in the code increases, the effort dedicated to software maintenance is increased.

This leads to the identification and correction of underlying issues in the software's architecture and design that might be causing recurring errors.

As these underlying issues are addressed, the internal quality of the software improves and the number of errors in the code decreases.

Balancing Loop 2: External quality

When the number of errors in the code increases, the effort dedicated to quality control is increased.

This leads to the identification and correction of errors.

As errors are corrected, the external quality of the software improves and the number of errors in the code decreases.

In this system, both balancing feedback loops compete to improve software quality, but they focus on different aspects of the process (external quality versus internal quality). As errors and underlying issues in the code are addressed and resolved, the internal quality of the software improves, which in turn reduces the amount of effort required for quality control and maintenance. This is similar to the thermostat example, where the two balancing feedback loops work together to maintain a desired temperature.

Clone of Internal Quality vs External Quality

Alfredo Artiles

The trap: Rule beating

Rules to govern a system can lead to rule beating—perverse behavior that gives the appearance of obeying the rules or achieving the goals, but that actually distorts the system.

The way out

Design, or redesign, rules to release creativity not in the direction of beating the rules, but in the direction of achieving the purpose of the rules.

From “Thinking in Systems” by Donella H. Meadows

In this system, the rule is the number of tests that must be written weekly. The developer has a self-allotted time to be spent per week to write tests and there is an amount of time needed to write a good quality test. If the rule is changed to increase the number of tests mandated per week and the developer does not allocate more time to writing tests, then the programmer will meet the requirements of the rule by writing lower-quality tests.

Inspired by Rule Beating Trap by Luciano Gonzalez

Rule Beating Trap - Tests per week

Alfredo Artiles

Goal

Maximize working software that solves customers' problems while:

- Minimizing burnout

- Maximizing code maintainability

Not modeled:

- Internal quality

- Local development cycle

- Waterfall between frontend and backend

- Discovery and user stories definition

- Technical splitting

- Validation with customers

Activity: Intervention points

Alfredo Artiles

Stock: A backlog of pending tasks of features and improvements to be implemented in the software

Input Flow: New feature and improvement requests (coming from users, development team, etc.)

Output Flow: Implementation of features and improvements (developed by the development team)

Delay: The time it takes for the development team to analyze, design, develop, test, and implement the features and improvements in the software.

In this example, it's necessary to maintain a backlog of tasks that can satisfy development demands during the time it takes to analyze, design, develop, test, and implement the features and improvements. This backlog acts as a buffer in case there are delays in the arrival of new feature and improvement requests or in the availability of the development team's resources.

The development team needs to maintain a healthy balance in the backlog to ensure that there's always work available and, at the same time, prevent the backlog from growing to a point where it becomes difficult to manage. To achieve this balance, the team may need to adjust the rate at which it accepts new requests or allocates resources to work on pending tasks.

Software Development Backlog Management

Alfredo Artiles

Drift to low performance - Software Quality

Alfredo Artiles

Post in my blog (Spanish): Entropía del Software y la Semana de Refactorización

"In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the "code and fix" nightmare, where the bugs become exponentially more expensive to fix as the project goes on."

Source: Is Design Dead? by Martin Fowler

Evolutionary Design & Software Entropy

Alfredo Artiles

In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the "code and fix" nightmare, where the bugs become exponentially more expensive to fix as the project goes on.

Source: https://www.martinfowler.com/articles/designDead.html

Evolutionary Design & Software Entropy

Alfredo Artiles

If you have a conviction, you should never stop advocating for it, even if it seems like everything has been said and you might sound repetitive. This is especially true in matters related to good practices in software development.

Let's take Test-Driven Design (TDD) as an example of a practice we want to promote. When someone talks about TDD publicly, like in a meetup, more people become aware of its existence and begin to adopt it. As more people practice TDD, more advocates for the practice emerge, who are eager to give new talks about its benefits. This creates a virtuous cycle of reinforcement that.

So far so good, but no cycle can grow indefinitely, and there is usually a limit to its expansion.

As more people learn and practice TDD, there are fewer people left to discover it, and demand for the topic decreases. This reduces the motivation to give talks about the subject, for fear of not bringing anything new or sounding repetitive. This creates a stable balance between supply and demand.

If we combine both cycles, we can see how the demand for talks and the number of people who know or practice TDD fluctuates. The problem with this is that, if we stop talking about the subject, these fluctuations could lead to a decrease in the adoption of the practice for a while until demand recovers.

This phenomenon can also be observed if we simulate it as a system of flows and stocks.

Run the simulation and observe how the number of people who stop adopting the practice, the number of talks, and their demand fluctuate.

These oscillations are something I've noticed in the Audiense Engineering team. Once we feel confident that most of us are familiar with certain practices, new members join, and we take longer to realize that we need to continue promoting them.

The conclusion I draw from all this is that ideally, there should be no periods of decline, and I can think of no other solution than to ignore the demand and persevere with our topic. We must continue defending our beliefs, even if it seems like we are repeating ourselves.

The Cyclical Dynamics of Adoption and Promotion

Alfredo Artiles

DevSystemsWiki Models