[euske]

I think the fundamental idea behind this is that "every decision must be rationalized", which is fine, but in reality it's difficult to pull off in my opinion. Because people (including myself) are so easily fooled, I'm afraid that it's often the case that we deliberately ignore certain (inconvenient) facts or unconsciously distort things. If we are really trying to rationalize ourselves, the decisions have to be reviewed by multiple people.

[xapata]

It's important to record that a decision was arbitrary, if it was.

For example, my father was in a meeting (snoring, as was his right as the longest serving member of the organization) when he overheard someone say, "We shouldn't change that, it's probably done that way for an important reason." Luckily, he woke up and interjected, "No, I picked that arbitrarily 30 years ago. Go ahead and change it." It'd have been better if he had written down the rationale, but don't judge. He wrote down plenty over the years.

[dasil003]

Not sure about that. Writing software requires heavy rationalization just to get a minimally working system. This is one reason some people aren't cut out to be programmers—they just don't have to patience to deal with the pedantic requirements of implementing cold, hard, unambiguous system logic.

I think it's more about documentation of that rationalization, and I wouldn't want to raise the bar on this by requiring a review. The value of every engineer just braindumping the roughest cut of their thinking already provides a tremendous amount of value over the history of a long-lived code base. Personally I do this in commit messages even for solo projects, but for larger teams/code bases/SOAs a more formal document-based approach allowing for diagrams and additional metadata is highly valuable if done consistently.

[dllthomas]

Rationalization or reasoning? I'm not sure which you're talking about, and the meaning of your text winds up being pretty different in each case. I'm not sure I disagree with either.

[cortesoft]

I don't think that is the fundamental idea... I think it is more about recording the decision making process rather than making sure it is rational.

The point is that, in the future, you can look at the doc to know why a decision was made.

You can then use that info when you are faced with deciding to make changes; maybe the circumstances changed and you now want to make a different decision. Or, maybe there are reasons that were forgotten, and you really should keep the system as it is.

You might read the ADR and realize the reasons were arbitrary and there wasn't a particularly good reason to choose what they did... that is good info to have!

I feel like this is a way to avoid a Chesterton Fence situation.

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

[qznc]

I would agree that ADRs are not really necessary if you work alone. Maybe not even within a team if it stable over a long time.

Where ADRs are helpful is when many teams cooperate and if people come and go. The reviews happen implicitly because the decision is discussed among many people.

[janee]

I'm not sure. I work in a small stable team and I had to do a tech due diligence report... it's really amazing being able to go two years into the past and pull the exact reasons why certain design decisions were made.

Not all our designs and decisions panned out ofc, but just having the articles already helped a ton getting through that DD and it really helps give new starts a much better feeling for the code base and where it came from