The Death of the Roadmap(debarshibasak.github.io)
debarshibasak.github.io
The Death of the Roadmap
https://debarshibasak.github.io/readables/blogs/death-of-roadmap.html
5 comments
If you developed (truly developed; including test cases and documentation and deployment strategy and change management and...) a 12 month roadmap in a couple days with Claude Code, then you seriously overestimated your time requirements in the roadmap. 2x, even 5x improvement maybe but not 300x. And you're left with a new codebase dripping in tech debt and structure nobody understands, and an agent that's likely to wipe your Prod instance and backups at some random future time.
I dont agree. For instance, one of the features in the roadmap was to build pgbouncer equivalent project internally. We did not underestimate the time it would take. You can have tech debt if you are not cautious. Internally, we do PRD-driven development; this is how we are not incurring tech debt.
> agent that's likely to wipe your Prod instance and backups at some random future time.
Funny that you mean, we are actually building a platform that builds guardrails, runtime policies, tool repo and classifiers that prevents agents from these operations.
> agent that's likely to wipe your Prod instance and backups at some random future time.
Funny that you mean, we are actually building a platform that builds guardrails, runtime policies, tool repo and classifiers that prevents agents from these operations.
> The 12-month engineering plan that I built 6 months ago - quarterly plan, hiring plan, integration roadmap - is now irrelevant
The 12-month plan was always a fantasy. Even planning 3 months out is too slow. Things change, new information comes in, plans get updated. You have to plan, of course, but never try to stick to the plan.
All hail the prioritized backlog. Toss your ideas on the board, prioritize regularly, work from top down at your preferred velocity.
The 12-month plan was always a fantasy. Even planning 3 months out is too slow. Things change, new information comes in, plans get updated. You have to plan, of course, but never try to stick to the plan.
All hail the prioritized backlog. Toss your ideas on the board, prioritize regularly, work from top down at your preferred velocity.
>never try to stick to the plan.
Yes. Again and again in my 15 year career so far, the effective leaders were those who understood that "stick to the plan" does not apply to project timelines, and the ineffective leaders were those who thought their job was to ask developers for estimates on every task and scold them every time that estimate was wrong, and that was their whole game plan.
Yes. Again and again in my 15 year career so far, the effective leaders were those who understood that "stick to the plan" does not apply to project timelines, and the ineffective leaders were those who thought their job was to ask developers for estimates on every task and scold them every time that estimate was wrong, and that was their whole game plan.
[deleted]