Timeline vs. Reality: When Planning Meets Development Chaos
The plan was beautiful. Reality had other ideas.
October 16: Sitting in class, looking at the 20-week timeline projected on screen. Four phases clearly delineated. Milestones at weeks 4, 7, and 10. It looked manageable. Logical. Sequential. Then Week 2 arrived, and the plan met reality. Turns out development doesn't follow neat timelines. Who knew?
The Original Plan
The course timeline was actually well-designed. Four distinct phases with clear objectives:
Weeks 1-3: Research & Ideation
Explore existing solutions. Build knowledge base. Test small experiments. Define the core problem we're solving.
Week 4: Midterm Ethics Review
Present functional prototype. Demonstrate ethical framework. Reflect on failures and successes. Analyze stakeholder impact.
Weeks 5-7: Iterative Building
Create five versions of core features. Test different approaches. Optimize for efficacy vs. performance. Refine based on feedback.
Weeks 8-10: Testing & Performance
Focus purely on making it work. Run comprehensive evaluations. Measure performance. Assemble final portfolio.
On paper, this makes perfect sense. In practice? Different story.
Week 2: The First Deviation
October 23: The MCP confusion. I thought MCP servers had to be installed locally. Spent a week researching installation procedures. Downloaded repositories. Read documentation about localhost endpoints.
This wasn't in the plan. Week 2 was supposed to be "explore HuggingFace and define core problem." Instead, it became "get blocked on infrastructure misunderstanding."
Then the professor clarified: MCP servers are hosted by service providers. GitHub offers api.githubcopilot.com. We don't install them—we configure URLs.
Breakthrough moment. One message unblocked a week of confusion. But the timeline was already off.
Planned: Define core problem
Reality: Unblock infrastructure confusion
Lesson: You can't predict what you don't understand yet. Week 2's confusion wasn't a failure—it was necessary learning.
Week 3: The Voice Complexity Wall
October 28: Trying to integrate Whisper for voice processing. Audio library errors everywhere. PyAudio won't install. PortAudio missing. Sound backends failing on HP AI Studio's Ubuntu environment.
ModuleNotFoundError: No module named 'pyaudio'
OSError: PortAudio library not found
RuntimeError: Failed to initialize audio backend
Days spent fighting audio drivers. The plan said "test small AI experiments." Reality said "learn about Linux audio stack compatibility."
The pivot: build chat interface first. Prove the pipeline works with text before adding voice complexity. Voice becomes Phase 2, not Phase 1.
Planned: Voice-first demonstration
Reality: Chat-first with voice later
Lesson: Simplify ruthlessly. The goal is proving the concept works, not implementing the final vision immediately.
Week 4: Midterm Success (Sort Of)
November 7: Midterm ethics review. Presented working demonstration—three assignment algorithms, Gradio interface, MCP JSON output generation.
The ethics framework was solid. Four pillars: Data & Privacy, Bias & Fairness, Transparency & Explainability, Autonomy & Human Agency. Stakeholder analysis complete. Reflections documented.
But the demo was chat-based, not voice-based. The original vision was "voice-controlled Kanban board." What we delivered was "text-controlled Kanban board that will eventually have voice."
Was this a deviation from the plan? Yes. Was it the right call? Also yes.
What Worked
- Phase gates forced reflection we would've skipped otherwise
- Ethics framework developed organically alongside technical work
- Chat interface proved the full pipeline before voice complexity
- Jupyter notebook with 8-cell template made demo reproducible
What Was Behind
- Blog documentation sparse—needed more video logs
- Voice integration still unresolved
- Actual API execution not yet implemented (just JSON generation)
Week 5-6: The Documentation Alarm
November 13: Professor checks blogs. "First red flag alarm." Most students, including me, behind on documentation.
"Your final piece of work for this class is not a product. It is a portfolio of learning. Failures have as much weight in terms of academics as successes do. You need to start tracking and cataloging your work."
The wake-up call. Documentation wasn't a "Phase 5" task. It was continuous. Ongoing. Essential.
The plan assumed we'd build first, document later. Reality revealed that post-hoc documentation loses context. Video logs needed to happen in real-time, not as retrospective summaries.
Planned: Documentation in Weeks 8-10
Reality: Documentation every week from Week 1
Lesson: Ideate → Create → Reflect is a cycle, not a sequence. Reflection can't wait until the end.
The Critical Moments That Changed Everything
Looking back, four moments shifted the trajectory more than anything in the original timeline:
October 22-23: MCP Discovery
Professor clarified hosted MCP endpoints vs. local installation. Breakthrough moment that unblocked API integration. One conversation worth a week of research.
October 28: Voice Pivot
Whisper audio errors led to strategic pivot: chat interface first, voice later. Simplification that made everything possible.
November 7: Phase 1 Demo Success
Working demonstration with three algorithms proved the concept. Validated that simplified approach worked. Earned momentum for Phase 2.
November 13: Documentation Reality Check
Professor's red flag alarm about blogs. Shifted strategy to video logs. Changed understanding of what "portfolio of learning" means.
None of these moments were in the original plan. All of them were essential.
What The Timeline Couldn't Predict
Some things are genuinely unpredictable at the start of a project:
Technical Unknown Unknowns
- Which audio libraries work on HP AI Studio's Ubuntu environment
- Whether MCP servers need local installation or hosted endpoints
- How much GPU memory Whisper Large V3 actually requires
- Real-world latency for voice → action → feedback loop
Conceptual Unknown Unknowns
- What "good" bottleneck detection looks like in practice
- How to measure "T-shaped skill development" quantitatively
- When prompt engineering is "done" vs. needs more iteration
- Whether teams will actually accept AI task suggestions
Academic Unknown Unknowns
- Balance between portfolio breadth and prototype polish
- How much broken code is acceptable in "development class"
- Attribution standards for Claude-assisted development
- When documentation becomes more important than building
You can't plan around what you don't know you don't know. That's why buffer time matters.
The 48-Hour Buffer Rule
Everyone messes this up. Final deadline is Thursday of Week 10. So we plan to finish everything by Thursday of Week 10.
No buffer. No margin for error. No room for chaos.
The veteran developer wisdom: internal deadline should be Tuesday of Week 10. That gives 48 hours for unexpected problems:
- API rate limits you didn't know existed
- Models that suddenly stop responding
- Files that get corrupted
- Gradio interfaces that break on deployment
- Audio drivers that worked yesterday but not today
- Documentation that takes longer than expected
Can't predict what will break. But can predict something will break. Buffer time isn't pessimism—it's realism.
What Actually Worked About The Plan
Despite deviations, the original timeline structure provided critical scaffolding:
Phase Gates Were Essential: Midterm review forced us to have something demonstrable by Week 4. Without that deadline, we would've kept researching indefinitely.
Clear Milestones Created Focus: "Working demo by Week 4" is more actionable than "make progress on the project."
Ethics Integration Worked: Having ethics review at midterm meant we developed ethical framework alongside technical work, not as afterthought.
Iterative Building Philosophy: "Create five versions" pushed us to try multiple approaches, not lock onto first solution.
What We'd Change
If starting over with current knowledge, these adjustments would help:
Start Documentation Day One
Video logs from Week 1. Screen recordings of every experiment. Real-time reflection, not retrospective summary. This should've been Week 1, not Week 8.
Simplify First, Complexify Later
Don't start with voice integration. Don't start with all three algorithms. Build simplest possible version that proves concept. Add complexity incrementally.
Budget More Time for Unknown Unknowns
Original plan: 20 weeks, use all 20 weeks. Better plan: 18 weeks of development, 2 weeks of buffer. Chaos will happen. Plan for it.
Prioritize Professor Conversations
The MCP clarification saved a week. The documentation alarm saved the project. Office hours aren't optional—they're critical course correction opportunities.
The Meta-Learning
The timeline vs. reality gap taught something bigger than project management:
"Working vs. not working is not pass/fail. This is a development class. The portfolio of learning—failures, successes, and implications—all have equal academic weight."
This changes everything. The timeline deviations aren't failures. They're the actual learning.
MCP confusion → learned about hosted endpoints vs. local installation. That's valuable knowledge that won't appear in final demo.
Voice complexity wall → learned to simplify ruthlessly. That's a principle that applies to every future project.
Documentation alarm → learned that reflection can't be post-hoc. That's a practice change that affects entire career.
The timeline was never the point. The learning along the way was the point.
Where We Are Now
November 13: Week 6 of 20. Not where the original timeline predicted. But not behind either—just different.
Completed
- ✓ Phase 1: Local setup with working chat interface
- ✓ Phase 2: Three assignment algorithms implemented
- ✓ Claude API integration for semantic understanding
- ✓ MCP JSON output generation
- ✓ Ethics framework with four pillars
- ✓ Midterm demonstration successful
In Progress
- ⚠ Voice integration (revisiting Whisper approach)
- ⚠ Actual API execution (currently just JSON generation)
- ⚠ Documentation catching up through video logs
- ⚠ Deployment to persistent HP AI Studio endpoints
Upcoming
- ○ Bottleneck detection algorithm
- ○ Comprehensive evaluation system (evals)
- ○ Latency testing and optimization
- ○ Final portfolio assembly
Different path than planned. But the destination is still reachable.
Conclusion
The plan was beautiful. Phases clearly delineated. Milestones evenly spaced. Deliverables well-defined.
Reality was messier. Infrastructure confusion. Audio compatibility issues. Strategic pivots. Documentation wake-up calls.
But messy doesn't mean wrong. The deviations taught more than following the plan would have.
MCP confusion taught us about hosted endpoints. Voice complexity taught us to simplify first. Documentation alarm taught us continuous reflection.
These weren't failures. They were the curriculum.
Timeline vs. reality isn't about one being right and the other being wrong. It's about recognizing that development is discovery. You can't plan around what you haven't learned yet.
The original timeline gave structure. Reality gave learning. Together, they're making Voice Kanban possible.
14 weeks to go. Plenty of time for more deviations. More unexpected problems. More breakthrough moments.
That's not a bug. That's the feature.
This is a development class. Not a product launch. The learning is the point.
And we're learning more than we ever planned.