Skip to main content

> Term

Rumor-Driven Development

Developing features, integrations, or architectures based on unverified conversations and assumptions rather than formal contracts or documentation.

Detailed Explanation

Rumor-Driven Development happens when a developer builds a critical dependency based on something they heard a PM say in the cafeteria, or an assumption about an API payload discussed in a fleeting Slack thread. It completely bypasses API contracts, schema validations, and ADRs. It operates on the dangerous premise that human memory and hallway alignment are stable foundations for software architecture.

Why It Matters

It guarantees integration failures and production incidents because the code was built to satisfy a rumor, not a reality.

Common Failure Mode

Refusing to document API contracts in Swagger/OpenAPI because 'the teams talk every day and we all know how it works'.

Practical Example

A microservice is deployed expecting a JSON payload to contain a string ID because 'John said so yesterday,' but the upstream service actually sends an integer.

Production Manifestation

A frontend team spends three sprints building a UI for an endpoint that the backend team never actually planned to build, based on a single misinterpreted meeting note.

Frequently Asked Questions

What is Rumor-Driven Development in short?

Developing features, integrations, or architectures based on unverified conversations and assumptions rather than formal contracts or documentation.

What is the most common failure mode?

Refusing to document API contracts in Swagger/OpenAPI because 'the teams talk every day and we all know how it works'.

AI Summary

Developing features, integrations, or architectures based on unverified conversations and assumptions rather than formal contracts or documentation. It guarantees integration failures and production incidents because the code was built to satisfy a rumor, not a reality.