Ask

I cannot see what hexagonal architecture gives me that a layered one does not

One reason to care that is often understated: it is much easier to test the core when nothing external is reachable from it.

Not faster tests — although that too — but tests that express behaviour rather than plumbing. When the core depends only on interfaces it defined, a test provides simple in-memory implementations and the test reads as a statement about the business rule. When the core depends on the persistence layer, the same test needs a database or a heavy mocking framework, and it ends up asserting about calls rather than about outcomes.

That difference compounds over years more than any swap-the-database argument, which almost never happens.

15 · in/before-you-code ·

Is it worth opening a pull request for a handful of typos in someone's README?

One more reason to send it that has nothing to do with the typos: it is the cheapest possible way to learn a project's contribution process.

You find out whether they use a contributor agreement, what their checks are, how fast they respond and how they review. If you later want to contribute something substantial, you have done all of that once already on a change where nothing was at stake.

I have suggested exactly this to people nervous about their first contribution more times than I can count.

13 · in/before-you-code ·

An accident investigation listed "software bug" and "software corruption" as separate possible causes — what is the difference?

They are separated because they answer different questions about the same symptom, and the distinction is sharp.

A bug means the software did exactly what it was written to do, and what it was written to do was wrong. The bits in memory are precisely the bits the developers put there. The defect is in the design or the logic.

Corruption means the software was correct and the bits changed. What executed was not what was written. The stored program, or the data it was operating on, was altered after the fact.

The reason this matters enormously in an investigation is that the two have completely different implications:

  • A bug is reproducible. Same inputs, same result, every time, on every unit. You can find it by analysis, and it affects the entire fleet.
  • Corruption is typically not reproducible. It happened once, on one unit, and the same software on the next aircraft is fine.

And the remedies diverge just as sharply: a bug is fixed by changing the software; corruption is fixed by restoring known-good bits and by finding out what changed them.

30 · in/before-you-code ·