5 ms·
"Plans Are Worthless, But Planning Is Everything" So i see the usefulness of design docs to be threefold: 1) Writing it all down in one place. You've got ton
by jmchuster 5y ago
"Plans Are Worthless, But Planning Is Everything"
So i see the usefulness of design docs to be threefold:
1) Writing it all down in one place. You've got tons of whiteboard meetings, random discussions by the water cooler, random slack threads, ideas you think up in the middle of the night, different asks and different reqs coming in from different teams. It's useful to formally write it all down. And then once you see it all in one place, you can more easily see which parts of conversations you forgot, which decisions that you thought you all agreed on in the meeting but people actually thought you agreed on a different outcome. You can see if there are any contradictory points -- does one decision you agreed on in one discussion actually make it impossible to follow the decision you agreed on in another discussion. You've now got the big picture and see things now you're all zoomed out, that you couldn't see when each discussion was just drilled down into a single component or aspect.
2) Coordinate for review. So now it's all written down, and everyone can go through and see if there's anything that they missed. Are there actually any blockers in here? You can now send it out to all the concerned parties and they can make sure that you didn't miss anything, that all concerns and asks are being properly covered. Are all the original requirement actually being handled by this design? How long is this actually going to take now for all the involved teams and people to do. Much easier to do when you've got a complete list of everything you need to do.
3) Documents your original intent. So now you're off and implementing it all, and of course you end up building something completely different from the design doc. But it's still important to go back to it and be able to see, what were all of these original concerns and blockers and worries that we had? The design doc says we made this decision because of this showstopper, we ended up doing it a different way, but did we properly account for that in our final implementation. Why did we even want to design it this way in the first place, does that constraint still hold today, and will our end result fail because we ignored it.