A property of a good design

is the reduction of the median rate of change across code elements (methods/classes).

»
Author's profile picture Dragan Stepanović

Most of the behavior we observe

is non-linear in nature, with some exponentiality in it.

»
Author's profile picture Dragan Stepanović

If you need to take time to understand the code before you start refactoring

then the refactoring step you plan to do is probably already too big.

»
Author's profile picture Dragan Stepanović

On measuring good design

It’s close to impossible to measure good, testable design, but over the years two interesting metrics settled in my mind that are a fairly good indication of the presence of clear, explicit code that speaks the domain:

»
Author's profile picture Dragan Stepanović

Before I, an engineer, believe you, an engineer

that “pressure from product and business made us produce this mess in the code” I need to see how tight your feedback loops are.

»
Author's profile picture Dragan Stepanović

On influencing change

Some of the things I think about when asked how to influence change in teams/orgs as a Principal/Staff engineer:

  • Invest time in building relationships before (big) course-correcting. In the start: a productive relationship is more important than being right. Spend time working together with people and sharing the constraints they are facing day-to-day, it will help you understand their context which makes your future interventions more likely to be useful.
»
Author's profile picture Dragan Stepanović

TBD + TDD + mob programming is way less YOLO

than working on an isolated, long-lived feature branch, with a delayed review, integration feedback, and a lack of tests.

»
Author's profile picture Dragan Stepanović

Change failure rate is a lagging indicator of lead time to change

If you halve the change size, your deployment frequency goes up twice, and now in order to keep the same change failure rate % as before you have to have twice as many failures per change.

»
Author's profile picture Dragan Stepanović

The paradox of automated tests as a safety net - as the testability of a codebase goes up, the ROI for test automation goes down?!

Automated tests as a safety net are most valuable in codebases with high risk when making a change. Those are conflated, coupled codebases where: 1) the average rate of change per element (method/class) is high and 2) the risk of introducing problems with a change is high (too much coupling). The latter is a consequence of the former, and codebases with long methods and classes inherently exhibit these characteristics.

»
Author's profile picture Dragan Stepanović

You can force yourself to tease out domain logic

by intentionally not adding integration tests.

»
Author's profile picture Dragan Stepanović