liveBook · Manning

Change request

As explained in Shipping Go: Develop, deliver, discuss, design, and go again

An RFC is a written proposal for a software design or change that invites review and discussion before implementation.

A change request, or RFC, is a written design proposal shared before implementation. It gives a team a chance to review the plan, question assumptions, and avoid building an over-designed solution that later needs rebuilding. section 11.3

Use an RFC to create a practical feedback loop:

  • Write the proposed design before development begins. section 11.3
  • Place the document in the repository so teammates can review it. section 11.3
  • Refer back to the proposal while implementing and evaluating how the system was built. section 11.3

Avoiding an expensive refactor

After two weeks of development, an accelerated refactor deadline exposed an over-designed solution. A repository RFC could have made the design discussable before implementation and reduced the risk of rebuilding it. section 11.3

How Shipping Go: Develop, deliver, discuss, design, and go again covers it

How deep it goes
Explains the practice and repository placement but stops short of prescribing an RFC template or approval workflow.
Examples
Uses a rushed refactor and repository design documents as concrete examples.
What it assumes
Assumes software development experience while teaching the value of planning and design review through a workplace failure.
What you can do after
Apply it by documenting a design in the repository and inviting discussion before writing the implementation.
How it connects
Connects design review with software development, refactoring, repositories, testing, and delivery.

Also explained in

Compare how 2 books explain change request →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Shipping Go: Develop, deliver, discuss, design, and go again. The section links point to the parts of the book it draws on.