Documenting Architecture Decisions

We used this at my last company. We backported decisions into them as documentation. People sometimes referred to them, but not often. It was hard to take what was a huge list of docs, some of which had been obviated by others, and truly grok them all. But I don't have a better idea for how to solve the problem. I would say it worked OK, but not great.

We use them at my company. I love how new engineers can't just come into our codebase and start doing huge refactors. ADRs kind of force them to explain their rationale. We also use them to upvote on whether an architectural change should be implemented or not.

We use them. They have been incredibly helpful. The concept has spread to our product team making product decisions!

This is the kinda stuff I expect to find in this kind of community! ADRs are a good topic that can help teams act more mature.

And less general career questions and low-level "what technology should I learn" 🤔

This is interesting! I think conceptually we've tried stuff like this but never had a standard to point to. I think it also helps figuring out when and why a decision was made even if you are an "expert", as we all forget

I haven't seen mentioned in the post but there is a template for this here: https://github.com/adr/madr/

Also those things are pretty much mandatory when you write surgical or healthcare devices. They have weird names like SDD (detailed design) or SDS (detailed specifications). There is some info about it here: https://en.wikipedia.org/wiki/Software_design_description

I like them a lot. Sometimes I use it as an agenda to sell an idea in a meeting. Othertimes I backport them after a decision has been made. It’s the context that drives a decision that easily gets lost to time.

I’ve been burned when a technical decision hurt us down the road and no one could really remember why we made it to begin with.