Banksalad: Tech Specs Are a 'Discussion Room,' Not a Document… Clearing Up Agile Misconceptions

Banksalad Tech Lead Ryu Seong-du refuted the common belief that writing a Tech Spec violates Agile principles. His argument is that what the Agile Manifesto warned against was not document writing itself, but the practice of valuing documentation over working software, and that modern collaboration tools can resolve this issue.

The Essence of the Tech Spec: A Discussion Room, Not a Document

Kent Beck once criticized document-based communication as one-directional and inefficient, but this stemmed from the absence of real-time collaboration tools in the environment of 2001. Tech specs written using modern tools such as Notion, Google Docs, and Slack enable Q&A and immediate feedback, maximizing the interactive spirit of Agile.

A tech spec is essential to write in the following situations:

• Projects requiring collaboration among 2 or more people
• Work that requires creativity and thus needs feedback from diverse perspectives

Feedback given after code implementation is difficult to incorporate due to sunk cost, but discussion at the tech spec stage prevents this problem in advance.

Management Policy: No Updates, Just End of Life

Banksalad's tech specs are not required to be kept up to date. When a spec changes, instead of revising the existing document, a new tech spec is written, and the lifespan of the old document ends the moment it is deployed. This is similar to how meeting minutes are rewritten when conclusions change.

Specifications that require ongoing reference are managed through IDL, test code, README, and the like, while tech specs focus solely on clarity of the 'topic to think about' and 'points for feedback.' Formal flaws (typos, letter spacing, etc.) are not grounds for rejection, and drafting takes 1-2 days, with feedback typically completed within about a week.