|
|
|
|
|
|
by vemv
2139 days ago
|
|
|
Quite ironically (given it's Github who are defending ADRs in the article), I avoid ADRs by using Github more richly: before working on a branch at all I create a substantial issue (think: multiple paragraphs, links to related issues/PRs, etc) and try to ping the team for feedback. The design process will ideally happen asynchronously, as comments posted in the issue. That way, a truthful trail of diverse considerations will be left in written form. Contrariwise, ADRs can be too written excessively after-the-fact, by a single person. I have seen them degenerate into bureaucracy ("we designed X because X seemed the best option"... how informative). |
|
|
If that's the most they can say, I'd rather that be surfaced. Knowing the decision was made in haste, with shallow consideration, is better than wondering if it was. And actually, that's probably the right way to make some decisions, if they seem likely to have a small difference in value between the many options it doesn't make a lot of sense to burn too many cycles making sure of that.
Once decisions come around to bite you, you can start to look at whether the decisions that are actually proving costly were the ones that were made lightly.
At least, that's how I'm thinking about it before getting into the weeds of it.