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.

I’ve been thinking of ways I can encourage students to get knowledge out of their head and experiment. Both so I can give feedback and to get them in the habit of checking their own understanding. I think unit tests might be an effective tool.

A previous post got me thinking about how principles can be measured and what value such measures could provide.

SMART is a set of criteria for setting effective goals. I recently saw a recommendation that architecture principles should be SMART, but I’m not convinced.

I previously enumerated a set of properties that underlay self-documenting code. Is there really a need for another set of properties?

I’ve been pondering properties of self-documenting code. Comparing self-documenting properties against SOLID lead me to realize Information Hiding, or conceptual scope, is a central theme of SOLID.