Banksalad Cuts Communication Cost to O(N) by Requiring 'Tech Specs' Before Development

Banksalad developers follow a common process of writing a Tech Spec before writing code. This measure addresses communication inefficiencies that arise in a growing organization, such as reluctance to document, inability to understand legacy code, and reliance on offline explanations.

Structural Change in Communication Cost Previously, for N features, various channels such as code, writing, and verbal explanations were mixed together, causing communication complexity to reach as high as O(3^N). After introducing tech specs, all work became connected via spec links, greatly reducing complexity to O(N). The approach involves defining large tasks as specs, breaking down milestones into Jira subtasks, and replacing PR descriptions with spec links.

Tech Spec Template Structure Banksalad's tech spec references Lyft's format and consists of the following elements.

• Summary: Organizes who/what/when/where/why in about 3 lines
• Background: Project motivation, user problem, whether there were past attempts
• Goals and Non-Goals: Clarifies measurable impact and project scope
• Plan: Detailed description of technical approach, diagrams, API specifications, etc.
• Milestones: Shares schedule including experiment plans and deployment dates

The Practical Value of Documentation Writing a tech spec is not a separate chore from coding. Since the implementation logic is described in code-level detail at the spec-writing stage, only the actual product application remains, making documentation itself part of the design process. This has improved the convenience of legacy records, reduced the burden on developers when schedules change, and built a transparent communication environment.