Why is a developer ("coder") not the ideal person to do requirements engineering — and how can developers still help?
Because requirements engineering needs special know-how most engineers lack, and a developer suffers from "creator blindness" — you cannot see the gaps in something you built. But developers still help: they know their code, how to change it, and the consequences of those changes.
It is tempting to assume the person who writes the code should also gather the requirements, but the two jobs need different mindsets:
- Special know-how — eliciting, negotiating and documenting requirements is a distinct skill set (communication, conflict resolution, moderation), not a coding skill. It is genuinely hard for normal engineers to do, and being excellent at one says nothing about the other.
- Creator blindness — whoever built or designed something is the worst-placed person to spot its missing or ambiguous requirements, because they unconsciously fill every gap with their own assumptions. The gap is invisible precisely because their mind supplies the answer. Requirements engineering has to overcome that blindness, which in practice means someone with an outside view.
But developers are a big help, not a hindrance:
- They know their code and how to change it, so they can say what is cheap versus ruinously expensive to require — information that shapes what is worth asking for at all.
- They understand the consequences of their actions — the downstream impact a requirement will have on the rest of the system.
Tip: This is why requirements engineering is typically done by a requirements analyst / business analyst (an outside, problem-focused role) with developers as expert consultants — not by the developers alone, and not without them either.
Go deeper:
Curse of knowledge (Wikipedia) — the cognitive bias underneath creator blindness: once you know a thing, you can no longer model not knowing it.