Design docs are a heavy-weight way to accomplish 3 major things, roughly in the order of importance:
1) Get feedback from your peers and other teams who need to interface with your design. Your design, or the problem you think you are tackling, could change based on their feedback.
2) Future readers can get a lot of context. Specifically, the design doc documents the trade-offs you considered and chose; this helps future engineers fully understand the problem space before second-guessing major decisions.
3) Leave some trace that you initiated/drove an effort of some design, for career/promotion purposes. You can demonstate how many stake holders/teams your work had to touch, and how difficult the problem & solution are based on various metrics in the design doc (# of ppl that participated in the review, # of services/components your design had to touch, etc).
Personally this is my least favourite reason to write a design doc, mostly because I find people write heavy-weight design docs when it serves no other purpose than for perf, and design docs are often.. embelished when they dont need to be.
Instead of a design doc, you can just file a bug, or shoot an email to a wider team, to accomplish the 3 things above. However, it becomes increasing inefficient to solely rely on bugs/email as the # of peers/stake holders increases, the scope/complexity of your project increase, or the communication overhead in your company increases.
I think it really depends on how mature, how complex, how isolated, and how big your project/working group is.
Where does your work fall, and what kind of process do you personally use to accomplish 1,2 & 3?
1) Get feedback from your peers and other teams who need to interface with your design. Your design, or the problem you think you are tackling, could change based on their feedback.
2) Future readers can get a lot of context. Specifically, the design doc documents the trade-offs you considered and chose; this helps future engineers fully understand the problem space before second-guessing major decisions.
3) Leave some trace that you initiated/drove an effort of some design, for career/promotion purposes. You can demonstate how many stake holders/teams your work had to touch, and how difficult the problem & solution are based on various metrics in the design doc (# of ppl that participated in the review, # of services/components your design had to touch, etc). Personally this is my least favourite reason to write a design doc, mostly because I find people write heavy-weight design docs when it serves no other purpose than for perf, and design docs are often.. embelished when they dont need to be.
Instead of a design doc, you can just file a bug, or shoot an email to a wider team, to accomplish the 3 things above. However, it becomes increasing inefficient to solely rely on bugs/email as the # of peers/stake holders increases, the scope/complexity of your project increase, or the communication overhead in your company increases.
I think it really depends on how mature, how complex, how isolated, and how big your project/working group is.
Where does your work fall, and what kind of process do you personally use to accomplish 1,2 & 3?