Why Developers Aren’t to Blame for Slow Releases: Insights from Baidu’s Tech Salon

Key Findings

First, developer productivity is surprisingly consistent; about 75% of engineers complete a task within 175 hours regardless of type or size.

Second, inserting a new task mid‑stream introduces “reaction time” as stakeholders pause to reprioritize, which wastes significant time.

Third, the handover from coding to testing and release adds additional delay.

What Actually Holds Up Development?

Vague Requirements

Unclear or incomplete specifications force developers to guess user intent, leading to rework. The article cites Sprintly’s “As a ___, I want ___, so that ___” template, which often fails to capture the full feature intent.

Changing Requirements

Continuous requirement changes disrupt progress. A Hacker News user likened it to finishing a wall only to be told the wall’s position must change. Building interactive prototypes before coding can reduce such surprises. Agile does not mean unlimited scope changes; learned knowledge should be incorporated into future iterations.

Sprintly also offers a time‑estimation feature that predicts how long remaining work will take, helping teams see the impact of added tasks.

Task Handoff

Interrupting a developer halfway through a task to start another (or to do both) creates “task handoff” problems. Data from the salon shows variation in completion times among senior developers, and forced multitasking further degrades productivity.

Joel Spolsky advises never to let programmers work on two things at once; managers should remove obstacles and only interrupt when absolutely necessary.

Taking Responsibility

Managers should create an environment that supports developers rather than blaming them. Recommended steps include:

Ensure the team understands the true user need and gains consensus.

Create task modules or templates that give developers the authority to reject ill‑defined work.

Avoid unnecessary interruptions; assess the productivity impact before sending emails or commands.

In short, delays are often a symptom of management workflow rather than developer slowness.