So many great lines, as usual:

- "Breakage" is a social construct

- Everyone can change everything -- of course! -- but not if tests break -- also of course!

- You basically repeat yourself another time, saying, like, I really meant it the first time, don't just rip it to shreds, please.

Interesting, maybe I should had gone into hardware (assuming it's embedded software not literal hardware). I've always said unit tests is like pouring concrete on your code. It will solidify and keep you from making changes. Which is ironic that the motivation is about changing things more as the article suggests:

> quality improvements are perceived as worthwhile if and only if they accelerate the rate at which the program is changed

Every company I've worked for shoots themselves in the foot doing this. Tests should mostly happen when the code is complete, and nowadays almost no company commits to this kind of workflow. There are ways to develop an app such that you can layer completed code on top of completed code adding tests as you go, but this has implications on the size and types of teams which is above the pay grade of an engineer.

To me it's one of the biggest frustrations with the software industry and how every job is always a mess and constantly putting out fires when it could easily be a smooth and predictable process like a lot of other engineering fields.