software-development

This and other concurrency problems often fall into the “you just have to know how to not get it wrong” camp. If you know to write an automated test for it, you probably know enough to reason about it and get it right. For very important things, sure, maybe write a test, but these tests are very expensive to write and maintain. It’s often cheaper to recognize (and train other team members to recognize) these scenarios and use a higher isolation level. Postgres makes this easy because serializable doesn’t come with a huge perf penalty (mostly memory, I believe). I’m strongly in the TDD camp too, btw. So I don’t say this flippantly. I appreciate this article bringing further awareness to this. Also, I cannot recommend partitioning (and event sourcing) enough to eliminate and simplify these problems. Article on partitioning: https://github.c

Totally agree that it has lost its meaning. We call things “incomplete work” that are, well, incomplete work. I wrote more about it here: https://github.com/aaronjensen/software-development/blob/mas... Also the advice in the article about noticing the issues and tracing them to their root is spot on. We record setbacks and mistakes in our work logs for our team to see and socialize common problems so we can address them holistically.

sbellware may have more to add, but there isn't a name for it. We focus more on the "it" than the branding of it. We do use the word "continuity" to describe our goal: https://github.com/aaronjensen/software-development/blob/mas... > The words "equipment log" and "work product" sound pretty unique. We call them "material logs", as equipment logs are more or less a subset of those. Just think about the sheet in every bathroom at a store that says when it was last cleaned, or the clipboard attached to the factory machine that lists its maintenance record and problems. Or the patient record outside of the patient's door. "work product" just means, the product of our work. Nothing special about that one, I don't think. > Are Erl's SOA books and Yourdon's on OOP still relevant? I haven't read either, personally, though I have Yourdon's book en

Author here. I don't know that arbitrary is the right word. They were decided, and generally found to be superior to alternatives. We stick to them so as to avoid special variation (https://github.com/aaronjensen/software-development/blob/mas...). For example, correct reinforces the notion that things can be wrong, mistakes can be made, so we correct them. This is essential to our team culture. "Rather than" came from Eventide's norms and I wasn't there when it was discussed initially. It works for concepts other than renames, so it is more flexible, but I can't say that was the reason for the initial decision.

There’s another way that feels totally unnatural at first, but puts the subject (the most important part) of the commit message first. It makes the commit about the change and the code, rather than the author. This is how we do it in all of our projects. I fought it at first, but I was wrong and it’s a lot better. Example: EntityStore build method records the specifier argument when given Article about it: https://github.com/aaronjensen/software-development/blob/mas...