Theory
The bug that was never in the code
Metatech once shipped a billing module that calculated GST perfectly, and still made the client furious.
Why? The client had told the analyst 'invoice monthly'. The analyst wrote 'generate invoices at month end'. The developer built it for the calendar month end. The client meant 30 days from each customer's signup date.
Every line of code worked. The communication chain failed at hop 2 of 3. No debugger can find this class of bug, and it is the most expensive class in the industry.
Theory
The nervous system, not the small talk
People imagine communication as the pleasantries around the real work. In a software team it is the nervous system: the only way 8 brains working on one codebase stay one organism. Signals travel as stand-ups, tickets, pull-request descriptions and client calls. When the nervous system is slow or noisy, the hands stop coordinating, no matter how strong each hand is.
Theory
What communication actually does for a project
The four jobs an exam answer should name:
- Requirement clarity: needs travel client to analyst to developer; good communication fights the degradation at every hop.
- Coordination: who is building what, in which order, against which interface; prevents two people breaking each other's work.
- Early risk surfacing: a blocker said aloud in today's stand-up costs 1 day; hidden, it costs a sprint.
- Stakeholder trust: clients tolerate delays they hear about early; they leave over silence.
At a glance
Project management runs on communication instruments; each has its own failure signature.
| Project activity | The communication instrument | What failure looks like |
|---|---|---|
| Daily coordination | Stand-up meeting, time-boxed | Two developers build conflicting changes for a week |
| Task tracking | Tickets with clear descriptions | Work done twice, or not at all, nobody sure |
| Code review | Pull-request description and comments | Reviewers guess the intent, defects slip through |
| Client relationship | Status reports, demos, early bad news | Surprise at delivery, trust destroyed |
Quiz
A Metatech developer discovers on Monday that an API his module depends on will be delayed by 2 weeks. The sprint review is on Friday. What should he do?
- Raise it in the very next stand-up so the plan can be adjusted immediately
- Wait for Friday's sprint review, since that is the official reporting meeting
- Quietly start building a workaround without telling anyone, to look resourceful
- Mention it only if the project manager directly asks about his progress
Show the answer
Raise it in the very next stand-up so the plan can be adjusted immediately
Blockers lose value with every silent day: raised on Monday, the team can re-plan, swap tasks, or negotiate the dependency; discovered on Friday, a week is already lost. Waiting for the official meeting, hiding behind a workaround, or answering only when asked are all silence dressed up as diligence, and silence is the most expensive habit in project communication.
Think first
Why do requirements degrade?
The client said 'invoice monthly' and got calendar-month billing they never wanted. Think first: WHY does meaning degrade as it travels client to analyst to developer?
Show the answer
Because every hop is a translation. The client speaks in business intentions, the analyst writes in requirement language, the developer reads in implementation terms, and each translation quietly substitutes its own assumptions for the missing details. Nobody lied and nobody was careless; ambiguity simply filled the gaps differently at each hop. The defence is communication discipline: restate what you understood, show examples ('so a customer who signs up on the 14th is billed on the 14th?'), and confirm in writing before building.
Watch out
The 'communication is overhead' trap
The classic junior mistake: treating meetings, tickets and documentation as interruptions to the real work of coding. Then one un-communicated API change costs the team a week, more than every stand-up that month combined. In exams, never write that communication 'wastes development time'; write that un-communicated work creates rework, and rework is the true overhead.
Theory
Where this thread goes next
This unit now gets practical: resolving conflicts and disagreements (next topic), communicating across remote and distributed teams, building rapport and cohesion, and finally how automation and AI change what teams communicate about. You met the management view in BCA202-02; here you are inside the software team looking out.
Summary
Key takeaways
- Most expensive project failures are communication failures, not code failures.
- Communication's four jobs: requirement clarity, coordination, early risk surfacing, stakeholder trust.
- Every project-management artifact (stand-up, ticket, PR description, status report) is a communication instrument.
- Requirements degrade at every hop because each translation fills gaps with different assumptions; restate and confirm.
- Blockers raised immediately cost days; blockers hidden cost sprints.
- Memory hook: the code compiles, the team must too.