Writing technical design docs

I have been working on the Jammming project, part of the Fullstack path.

One of the tasks is to write a technical feature request document, in which we outline the feature we are planning to add to the app, how we would implement it and potential caveats. The purpose of this in a team would be to plan ahead and share this plan with all stakeholders.

My question on this topic is: what do you do if during development you find new blockers you did not account for in the technical design document?
Would you update the document and re-share with the stakeholders before proceeding with the development? Would you add this alternative plan in the technical design or in the caveats?

This is not something specifically related to the project, but a question on the flow when you are part of a team.

1 Like

Is it a code roadblock or person? (lol)

In my experience, if there’s a fix for them in the allotted time of the dev cycle, and it’s easy enough to do and won’t break anything currently in the code, then you’d keep the stakeholders apprised and decide what to do. If it’s elaborate and will take time to investigate and carry out, then it might have to be pushed to the next dev cycle.

Got it!

In my case it was a code roadblock that was not indicated in the API documentation. In the specific, the majority of Spotify tracks returned a null value because of the user’s market.
Just handling the roadblock in the code (with conditional rendering) and updating the document with screenshots of what it would look like to make the stakeholders aware would be sufficient?

1 Like