planning-and-task-breakdown

Planning and Task Breakdown

Overview

"The plan is the task — 10 minutes upfront prevents hours of rework." Break work into small, ordered, verifiable tasks before writing code. Each task is a vertical slice that leaves the system in a working state.

When to Use

• Before implementing any feature spanning more than 2–3 files
• After writing a spec (follows spec-driven-development)
• When a task feels "too big to start"
• When multiple developers will work on related code

Skip when: The change is a single-file fix with obvious scope.

Core Process

Step 1: Read-Only Analysis

1. Read the spec (SPEC.md) or requirements — do not modify any code
2. Map the codebase:
   • Which modules are involved? (:app, :feature:*, :core:*)
   • Which layers? (UI → ViewModel → UseCase → Repository → DataSource)
   • What existing code can be reused?
3. Identify constraints:
   • Android API level requirements
   • Existing architecture patterns to follow
   • Library versions and compatibility

Step 2: Map Dependencies

1. Draw the dependency graph:
   • Data models → Repository → UseCase → ViewModel → UI
   • Room entities → DAOs → Database migrations
   • Navigation graph changes → Screen composables → ViewModels
2. Identify the critical path — what must exist before other work can start

Step 3: Vertical Slicing

1. Slice vertically, not horizontally:

   Wrong (horizontal):

   • Task 1: Create all Room entities
   • Task 2: Create all DAOs
   • Task 3: Create all repositories
   • Task 4: Create all ViewModels
   • Task 5: Create all screens

   Right (vertical):

   • Task 1: User can view item list (Entity + DAO + Repo + ViewModel + Screen)
   • Task 2: User can create new item (AddScreen + ViewModel + Repo insert)
   • Task 3: User can edit existing item (EditScreen + ViewModel + Repo update)
   • Task 4: User can delete item (swipe-to-delete + Repo delete + undo)

2. Each slice must:

   • Deliver observable functionality
   • Be testable in isolation
   • Leave ./gradlew build passing