Medallion architecture: bronze, silver, and gold

 A layered data organization system:

• Bronze: Raw, unprocessed data as it arrives from source systems. Preserves original state for auditing and reprocessing.
• Silver: Cleaned, deduplicated, and standardized data. Conforms to consistent naming and formatting conventions across the organization.
• Gold: Business-ready, curated datasets optimized for analytics and reporting. This is where data becomes actionable for business users.

This three-tier structure moves data from its raw form through progressive refinement, improving quality and usability at each stage.

See related TWOTW: ETL - extract, translate, load

Sources:

• Medallion Architecture: Bronze, Silver & Gold Layers Explained (2026 Guide)
• Data Lake Zones: Bronze, Silver, Gold Architecture | Conduktor
• Understanding the Three Layers of Medallion Architecture

SPACE framework metrics

The SPACE framework is a research-backed model for measuring software engineering productivity across five key dimensions: 

• Satisfaction/well-being
• Performance
• Activity
• Communication/collaboration
• Efficiency/flow

Developed by researchers from Microsoft and GitHub, it avoids traditional output-only metrics in favor of a holistic approach.

The Five Dimensions of SPACE Metrics

S - Satisfaction and well-being: How developers feel about their work environment, team dynamics, and health. This is measured through surveys, burnout signals, eNPS, and retention rates.

P - Performance: The outcomes and impact of development efforts rather than just the code produced. Key indicators include customer-reported defects, service reliability, and change failure rates.

A - Activity: The volume or count of actions performed within the development process. It tracks commits, pull requests, code reviews, and build completions, though it should be balanced with other dimensions to prevent misleading output measurements.

C - Communication and collaboration: How teams work together and share knowledge. This evaluates the quality of code reviews, documentation, and the clarity of communication across distributed teams.

E - Efficiency and flow: The ability to complete tasks with minimal interruptions and delays. Measurements focus on cycle times, deployment frequency, focused development time, and the speed at which code is merged.

source: AI overview

DORA metrics

DORA metrics are standardized key performance indicators developed by Google's DevOps Research and Assessment team to measure software delivery speed and stability. Engineering teams use them to identify bottlenecks, balance velocity with quality, and benchmark their delivery maturity against industry standards.

The Core DORA Metrics

The four primary metrics are divided into two categories:

Velocity & Throughput

• Deployment Frequency (DF): How often code is successfully released to production (e.g., multiple times a day vs. once a month).
• Lead Time for Changes (LT): The time it takes for a commit to travel from the beginning of the development cycle to production deployment.

Stability & Reliability

• Change Failure Rate (CFR): The percentage of deployments that cause a production failure and require immediate remediation.
• Mean Time to Recover (MTTR): The average time it takes an organization to restore service after a production failure or incident.

source: AI overview

Further reading: https://dora.dev/guides/dora-metrics/

SLI, SLO, SLA (service level indicator/objective/agreement)

Key Definitions & Differences

• SLI (Service Level Indicator): The actual measurement of a service's behavior, such as uptime or request success rate.
• SLO (Service Level Objective): A target value for the reliability of a service, defined by the SLI. These are usually internal goals.
• SLA (Service Level Agreement): A contract between a provider and customer that outlines expected service levels and consequences (like service credits) if targets are missed.

Practical Example

• SLI: The current success rate of user logins is 99.98%
• SLO: The goal is 99.95% success rate per month.
• SLA: If success falls below 99.90%, the company owes customers a refund. 

Key Takeaways

• SLOs should be stricter than SLAs to provide a buffer for error.
• SLIs (indicators) are used to measure SLOs (objectives).
• SLAs are typically legally binding and external, while SLOs are internal targets. 

Reference: https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli

Gherkin Syntax

Gherkin Syntax: Structured format (Given/When/Then) for defining behavior.

Gherkin is a plain-text language with a simple structure. It is designed to be easy to learn by non-programmers, yet structured enough to allow concise description of test scenarios and examples to illustrate business rules in most real-world domains.

Here is a sample Gherkin document:

Feature: Account Holder withdraws cash

Scenario: Account has sufficient funds

    Given The account balance is $100

      And the card is valid

      And the machine contains enough money

     When the Account Holder requests $20

     Then the ATM should dispense $20

      And the account balance should be $80

      And the card should be returned

source: https://support.smartbear.com/cucumberstudio/docs/bdd/write-gherkin-scenarios.html

Reference: https://cucumber.io/docs/gherkin/reference/

YAGNI

YAGNI ("You Ain't Gonna Need It") is an Extreme Programming (XP) principle stating that functionality should only be added when it is actually needed, rather than when it is foreseen. It prevents overengineering and reduces technical debt by avoiding the creation of unnecessary, complex features that often go unused. 

source: AI overview of Wikipedia

Key Aspects of YAGNI:

• Benefits: Reduces the cost of building, testing, and maintaining unnecessary code. It also minimizes the "cost of delay" for actual, needed features.
• Application: It is commonly used in Agile development to maintain a clean codebase and focus on current, tangible value.
• Drawbacks/Risks: If taken too far, it can lead to a lack of necessary architectural planning, making future refactoring difficult. It is not an excuse for ignoring security or essential design.

Example: Instead of building a complex, generic search algorithm for every conceivable scenario, you only implement the specific filtering required by the user right now. 

source: AI overview from martinfowler.com

When to Apply YAGNI:

• When tempted to write "future-proof" code.
• When features are proposed based on speculative, unverified future needs.
• When complex abstractions are added prematurely. 

source: AI overview of Reddit

Semantic Versioning (SemVer)

Semantic versioning (also known as SemVer) is a universal way of versioning the software development projects to track what is going on with the software as versions are being built almost every day. In brief, it's a way for numbering the software releases.

So, SemVer is in the form of Major.Minor.Patch. 

Semantic Versioning is a 3-component number in the format of X.Y.Z, where :  

• X stands for a major version. The leftmost number denotes a major version. When you increase the major version number, you increase it by one but you reset both patch version and minor versions to zero. If the current version is 2.6.9 then the next upgrade for a major version will be 3.0.0. Increase the value of X when breaking the existing API.
• Y stands for a minor version. It is used for the release of new functionality in the system. When you increase the minor version, you increase it by one but you must reset the patch version to zero. If the current version is 2.6.9 then the next upgrade for a minor version will be 2.7.0. Increase the value of Y when implementing new features in a backward-compatible way.
• Z stands for a Patch Versions: Versions for patches are used for bug fixes. There are no functionality changes in the patch version upgrades. If the current version is 2.6.9 then the next version for a patch upgrade will be 2.6.10. There is no limit to these numbers. Increase the value of Z when fixing bugs

Points to keep in mind : 

• The first version starts at 0.1.0 and not at 0.0.1, as no bug fixes have taken place, rather we start with a set of features as the first draft of the project.
• Before 1.0.0 is only the Development Phase, where you focus on getting stuff done. This stage is for developers in which the system is being developed.
• SemVer does not cover libraries tagged 0.*.*. The first stable version is 1.0.0.

source: https://www.geeksforgeeks.org/software-engineering/introduction-semantic-versioning/

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backward compatible manner
3. PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

source: https://semver.org/

Alarm Fatigue

Alarm fatigue or alert fatigue describes how busy workers become desensitized to safety alerts, and as a result ignore or fail to respond appropriately to such warnings. Alarm fatigue occurs in many fields, including construction and mining, healthcare, and the nuclear power field. Like crying wolf, such false alarms rob the critical alarms of the importance they deserve. Alarm management and policy are critical to prevent alarm fatigue. 

Examples

• Vehicle back-up alarms sound so frequently that they often become senseless background noise
• Electronic medical monitors tracking clinical information such as vital signs and blood glucose sound alarms so frequently, and often for such minor reasons, that they lose the urgency and attention-grabbing power which they are intended to have
• California Proposition 65 has been criticized for causing "over-warning" due to encouraging "meaningless warnings." There is no penalty for posting an unnecessary warning sign, and to the extent that warnings are vague or overused, they may not communicate much information to the end user. Many companies now routinely attach Prop 65 warning labels to any product of theirs that they think might possibly contain one of the 900 listed chemicals without testing to see whether the chemical is really present in their product and without reformulating their product, because it is cheaper to do so than to run the risk of being sued by Prop 65 enforcers.

Proposed solutions

• Identify by sound alone. Change alarm sounds to be softer and friendlier in order to improve identification of alarms. 
• Adjust the parameters and delays to alarms to match the traits and status. However, this directly trades sensitivity for specificity.
• Centrally monitor alarms where a trained person evaluates each alarm and distributes alerts only when necessary.
• Adjust automated alarm algorithms to be more specific and not overly sensitive to mitigate false alarms and balance sensitivity and specificity to still detect actionable conditions.

See also

• Alarm management – Usability factor in alarm systems
• Banner blindness – Tendency to ignore banner-size notices
• Compassion fatigue – Condition characterized by emotional and physical exhaustion
• False alarm – Deceptive or erroneous report of an emergency
• Habituation – Decrease in a behavioral response to a repeated stimulus
• Inattentional blindness – Condition of failing to see something in plain view
• Information overload – Decision making with too much information
• Normalization of deviance – Sociological phenomenon
• Semantic satiation – Psychological phenomenon

source: https://en.wikipedia.org/wiki/Alarm_fatigue

Feature Gate

A feature gate is a mechanism to configure which features are visible to users without changing application code. You might also hear them called feature flags or feature toggles.

When to use feature gates

Feature gates are commonly used as on/off switches to turn a certain system behavior on or off in production. They may be used:

• to enable certain features for a percentage of the total user base, for example, A/B testing
  
• to gradually ramp up a software release across the user base to limit the impact of any unanticipated system behavior
• to limit a new feature to specific users before the feature is ready for general availability in production
• to quickly turn off a particular feature for all users
• to target a specific set of users thereby implementing whitelisting

Statsig uses the term feature gates, as they act as a "gatekeeper" to new features.

Other Uses

In Kubernetes, feature gates are a set of key=value pairs that describe Kubernetes features. You can turn these features on or off using the --feature-gates command line flag on each Kubernetes component.

Microsoft Azure .NET provides the FeatureGate attribute that can be placed on MVC controllers, controller actions, or Razor pages to require all or any of a set of feature flags to be enabled.

Coding Priorities

Coding Priorities

If you were to ask three different friends to drop by the supermarket to pick up some asparagus, green beans, and corn, would it surprise you to find that one friend bought canned vegetables because were the cheapest, another bought frozen vegetables because they were easiest to cook, and the third bought fresh vegetables because they were organically grown and tasted the best? Can you at least imagine such a thing happening?

The three friends buy different types of vegetables for the same reason one programmer will emphasis speed in his code, another will emphasize small size in hers, and a third will emphasize simplicity--their choices differ because their priorities are different. (p. 17)

From book: Debugging the Development Process

I frequently refer to the section titled "Know Your Coding Priorities" (p. 18).

• Size: memory, storage, or bandwidth
  
• Speed: execution time to complete a task
  
• Robustness: resilience to bad input, i.e., hard to "crash"
  
• Testability: effort needed to verify expected behavior
  
• Maintainability: effort for someone else to fix a bug or add a feature
  
• Simplicity: experience another developer needs to read and understand the code,  dependencies, and interactions
  
• Reusability: you or other teams use the code in other use cases
  
• Portability: effort required to migrate to another platform (e.g., database, browser, mobile OS, cloud provider, etc)
  
• Readability: time another developer needs to correctly understand the intent by looking at a section of code
  

 

Software Architecture Styles

Software Architecture Styles

source: https://blog.bytebytego.com/p/ep68-top-architectural-styles

cargo cult

During World War II, American troops arrived by planes and ships to some Pacific islands and, during their stay, gave goods to the inhabitants. When the war ended, the troops stopped going to the islands and the natives stopped receiving the precious goods and gifts. And then there was an eye-catching phenomenon: the natives began to build monuments shaped like airplanes. They believed that by repeating exactly what they had seen those gods from heaven do, more planes would magically come with goods and gifts.

This phenomenon is what we call Cargo Cult. The concept is used as a metaphor to describe a very valid problem: the effort to try to replicate certain results by mimicking behaviors – rituals – without understanding the true causes that lead to those results.

source: The Opposite of Agility: Rituals, Ceremonies, and the Cargo Cult

See also: dogmatism (twotw)

Strangler Fig pattern

Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features from the legacy system are replaced, the new system eventually replaces all of the old system's features, strangling the old system and allowing you to decommission it.

source: https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler-fig

Modernize an application by incrementally developing a new (strangler) application around the legacy application. In this scenario, the strangler application has a microservice architecture.

source: https://microservices.io/patterns/refactoring/strangler-application.html

Short blog by Martin Fowler on the etymology: StranglerFigApplication

Onion Software Architecture

Onion Architecture is based on the inversion of control principle. Onion Architecture is comprised of multiple concentric layers interfacing each other towards the core that represents the domain.

Onion Architecture solved these problem by defining layers from the core to the Infrastructure. It applies the fundamental rule by moving all coupling towards the center. This architecture is undoubtedly biased toward object-oriented programming, and it puts objects before all others. At the center of Onion Architecture is the domain model, which represents the business and behavior objects. Around the domain layer are other layers, with more behaviors.

Domain Layer

At the center part of the Onion Architecture, the domain layer exists; this layer represents the business and behavior objects. The idea is to have all of your domain objects at this core. It holds all application domain objects. Besides the domain objects, you also could have domain interfaces. These domain entities don’t have any dependencies. Domain objects are also flat as they should be, without any heavy code or dependencies.

Repository Layer

This layer creates an abstraction between the domain entities and business logic of an application. In this layer, we typically add interfaces that provide object saving and retrieving behavior typically by involving a database. This layer consists of the data access pattern, which is a more loosely coupled approach to data access.

Services Layer

The Service layer holds interfaces with common operations, such as Add, Save, Edit, and Delete. The Service layer also could hold business logic for an entity. In this layer, service interfaces are kept separate from its implementation, keeping loose coupling and separation of concerns in mind.

UI Layer

It’s the outer-most layer, and keeps peripheral concerns like UI and tests. For a Web application, it represents the Web API or Unit Test project. This layer has an implementation of the dependency injection principle so that the application builds a loosely coupled structure and can communicate to the internal layer via interfaces.

source: https://www.codeguru.com/csharp/understanding-onion-architecture/

More: https://jeffreypalermo.com/tag/onion-architecture/

 

 

The Cobra Effect

source: https://sketchplanations.com/the-cobra-effect

Once the bounty was removed, the farmed cobras were released into the wild.

Postel's Law or the Robustness Principle

In computing, the robustness principle is a design guideline for software:

Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept").

The principle is also known as Postel's law, after Jon Postel.

In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.

source: Robustness principle (wikipedia)

This simple statement captures a significant concept in the design of interoperable systems. Many consider the application of the robustness principle to be instrumental in the success of the Internet as well as the design of interoperable protocols in general.

Time and experience shows that negative consequences to interoperability accumulate over time if an implementations apply the robustness principle. This problem originates from an assumption implicit in the principle that it is not possible to affect change in a system the size of the Internet. That is, the idea that once a protocol specification is published, changes that might require existing implementations to change are not feasible.

Many problems that might lead to applications of the robustness principle are avoided for protocols under active maintenance. Active protocol maintenance is where a community of protocol designers, implementers, and deployers work together to continuously improve and evolve protocols. A community that takes an active role in the maintenance of protocols can greatly reduce and even eliminate opportunities to apply the robustness principle.

source: The Harmful Consequences of the Robustness Principle (IETF)

In my opinion, the critical factor of the criticism is "protocols under active maintenance" and the assumption that "it is not possible to affect change." Most developers are trying to implement just one side of an established protocol and the task is simply to get the program to work and reduce its fragility. For this scenario, robustness is of benefit. For those developing protocols and reference implementations, strictness has the benefit of early detection of defects and ambiguous requirements.

Quod tegitur

Simpliciter pateat vitium fortasse pusillum:

Quod tegitur, magnum creditur esse malum

 

Let a defect, which is possible but small, appear undisguised.

A fault concealed is presumed to be great.

 

Variant translation: Conceal a flaw, and the world will imagine the worst.

https://en.m.wikiquote.org/wiki/Martial

My own take on this is:

• Secrecy breeds Suspicion
• Transparency breeds Trust

build-measure-learn

Eric Ries pioneered the idea of Build-Measure-Learn in his book, "The Lean Startup." It is a learning and feedback loop for establishing how effective a product, service or idea is, and doing this as quickly and cheaply as possible.

Follow these steps to use the Build-Measure-Learn feedback loop:

Step 1: Plan your experiment: learn, measure and build – including developing a formal hypothesis.

Step 2: Build a minimum viable product, and test it.

Step 3: Measure the results against your hypothesis to decide whether you can develop a viable business around your product.

Step 4: Learn from your results, and decide whether to persevere or pivot.

Then, cycle back to the beginning, and keep on going around the loop as you develop your product.

The biggest advantage of this technique is that it minimizes the risk and cost of creating products or services that no one wants, and helps you to "zero in" on something that customers will embrace.

source: https://www.mindtools.com/pages/article/build-measure-learn.htm

Additional reading

• http://theleanstartup.com/principles
• https://www.cleverism.com/how-build-measure-learn-cycle-really-works/

wagile

Wagile Methodology: A framework to integrate agile and waterfall methodologies and to digitalize corporate governance, decision management and project delivery.

The purpose is to align individual acting organisational units in a way, that the entire corporation can use its full potential and move as a single entity!

https://wagile.pro/

A portmanteau of waterfall + agile.

Chesterton's Fence

Don't ever take a fence down until you know the reason it was put up.

Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood. The quotation is from G. K. Chesterton's 1929 book The Thing.

sources:

http://igeek.com/w/Chesterton%27s_Fence

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence