Engineering Design Review
4 weeks · 0 milestones
Conduct a formal engineering design review of a real software design — either as author defending your own design, or as a reviewer leading the review of a peer's design. The review must follow a structured format: design document distributed at least 48 hours before the review, a written review checklist with specific questions prepared in advance, the review session with documented findings (issues, action items, and their severity), and a revision record showing what changed as a result of the review. Preferred proof: a design review in a professional or team context. Accessible alternative: a peer design review conducted with at least 2 qualified reviewers from an open-source project community, a university engineering programme, or a professional network — the design reviewed must be non-trivial (an architectural decision, a data model, or a protocol specification, not a single function). Proof artifacts: the review checklist and findings (analysis artifact) and the revision record documenting what changed and why (documentation artifact). Verification: one of the reviewers confirms the review was substantive — not rubber-stamping — and at least one finding resulted in a real change to the design.
Milestone map
Milestone map
3 milestones
Write a design document for a real or realistic software or systems engineering change. The change must be substantive enough to warrant a design review — examples include: adding a new API endpoint that integrates two existing services; changing the data model for a core entity; replacing one infrastructure component with another; introducing a caching layer; or implementing a new authentication mechanism. The design document must follow a standard structure: problem statement and context (what is broken or inadequate now); proposed solution (what you are changing and how); alternatives considered (at least two, with rejection rationale); design decisions and their tradeoffs; and open questions (questions that need answers before implementation can proceed). Free tool: GitHub Markdown, Google Docs, or any collaborative document tool.
Proof required
Submit your design document (800–1200 words, excluding diagrams). It must include: a numbered list of at least two alternatives considered with explicit rejection rationale for each; a section titled 'Open Questions' with at least two questions; and at least one diagram (architecture, sequence, or data model — draw.io is free).
What gets checked
- Alternatives are specific and technical — 'Option A: use Redis for caching; rejected because our team has no Redis operational experience and the added operational burden outweighs the latency benefit at current scale' is a valid alternative; 'we considered other options' is not
- Open questions are genuine questions the author cannot answer without external input — 'Should we use Redis or Memcached?' is not an open question if the alternatives section already answered it; 'What is the acceptable p99 latency budget for the new cache lookup?' is a genuine open question that requires stakeholder input
- Diagram accurately represents the proposed state, not the current state — a design document that shows only the existing architecture has not documented the change