Skip to content
master
Go to file
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
 
 

readme.md

Documenting Architectural Decisions

Presented by: David Ayers
Innovative Technology Professional | Passionate Lifelong Learner | Giant Nerd
Full Bio
@iamagiantnerd, iamagiantnerd@gmail.com

Talk Abstract

As technologists, we make architectural decisions all of the time; what we're not good at is recording the context surrounding the decision and properly communicating that decision to the rest of the team (or teams). Enter ADRs (Architecural Decision Records) -- a lightweight was to record and communicate these decisions.

Talk Description

"Why did we decide this?" – every developer in history, 12 months after making a decision.

As technologists, we make architectural decisions all of the time. What we're not good at doing is:

  • Socializing these decisions though the team/department (whoever participated in the discussion has the context, everyone else is out of luck!)
  • Recording the decisions, and more importantly, the context behind the decisions, in a way that our future selves (or anyone – someone just joining the team, for example) can look back and understand why the decision was made and what the factors that went into the decision were.

Enter ADRs. First proposed by Michael Nygard, Architectural Decision Records provide a way to capture these decisions as part of the codebase that you're working on; where the rubber meets the road.

In this short lightning talk, we’ll go through the case for ADRs and a simple primer and how to get started using this technique in your projects.

Links included:

The following links are referenced in the presentation:

Releases

No releases published

Packages

No packages published
You can’t perform that action at this time.