This series clarifies the Open-Closed Principle (OCP) with examples. This post applies the OCP to the system level with architecture patterns like ports and adapters.

This series clarifies the Open-Closed Principle with examples. This post will demonstrate the OCP through interchangable and composable dependencies.

This series clarifies the Open-Closed Principle with examples. This post will demonstrate how the OCP can be achieved through flexible behaviors like callbacks.

This series clarifies the Open-Closed Principle with examples. This post will demonstrate how the OCP can be achieved through flexible data.

The Open-Closed Principle, one of the SOLID principles, is crucial to reusable code and insulated problem domains. This series will clarify the principle with examples.

Dependency Inversion demands that abstractions belong to callers. This isn’t an immediately intuitive choice. I’ll break down the choices for where our abstractions can live and how each choice impacts kinds of dependency.

Only measuring total defects could incentivize misreporting. How could we measure defects in a way that aligns incentives with desired outcomes? I don’t have a sure answer, but here are some thoughts.

Releasing frequently requires repeatable confidence that changes are safe. Reliably verifying system health requires covering the many failure modes of a system. So, what are those failure modes?

Principles, patterns, and practices are common terms in software design, yet I’ve had a surprisingly hard time finding official definitions. Here I’ll try to define these terms and differentiate them.

Learning is hard. It’s easy to lose track of what we’ve achieved and only see how much we have yet to master. My mentee, however, found a simple and powerful way to build confidence and self-efficacy: progress journals.