Better Conversations Make Better Software
The quality of software is directly proportional to the quality of the conversations that produce it. I wrote that in response to a post by John Fattal arguing that engineers have to translate technical asks like observability, automated testing, and infrastructure as code into business impact, or get ignored. He’s right, and I’d push the idea further. Every conversation that touches the code shows up in the code eventually.
Conway’s Law, one level down
Melvin Conway observed that organizations design systems that mirror their own communication structures. Two teams that never talk produce two services with an awkward seam between them. Conway was describing the shape of the conversations: who talks to whom. I wrote about getting that shape right in Communication Should Take the Shortest Path. I think the quality of those conversations matters just as much.
Two teams can meet every week and still build a bad integration if neither one says what it actually needs. Most defects start as a misunderstanding: a requirement read two ways, an edge case nobody raised, an assumption that lived in one person’s head. The code is just where the misunderstanding finally shows up.
Engineers and product
Fattal’s point is about this conversation. “We need better observability” is a request product will nod at and put at the bottom of the backlog. “When checkout breaks, customers notice before we do, and it takes us two hours to find which service failed” is the same request with a cost attached. Two more translations, as examples:
- Automated testing: “Every release needs two days of manual regression. With a real test suite, we could ship the day the work is done.”
- Infrastructure as code: “If we lost the production environment tomorrow, rebuilding it would take weeks of clicking through a cloud console. With the infrastructure in code, it’s an afternoon.”
Engineers who skip that translation end up with good ideas that never get funded.
The conversation runs the other way too. A ticket that says “add CSV export” is half a conversation. Who needs the export? What are they doing with it? What happens if it ships a week late? The questions I listed in Speed Is Only Useful If You’re Going in the Right Direction, like what problem we’re actually solving and how we’ll know it’s solved, only work when someone asks them out loud and someone else answers.
Code review and pairing
A code review is a conversation that happens to be written down, and a lot of them are bad conversations: a wall of naming nits, or an approval with nothing attached.
A good review asks about intent. What problem does this solve? What did you try and throw away? “I misread this function as validating the input; should the name say what it does?” is more useful than “rename this.” I argued in Review the Outcome, Not the Output that the valuable question is whether a change accomplished its goal. You can only answer it in a review that talks about the goal.
Pairing moves the conversation earlier. The cheapest review happens while the code is being written, when “wait, why are we doing it this way?” costs a minute instead of a rewrite. Assumptions get said out loud before they harden into code.
Customers
The most important conversation is the one engineers are most often left out of. Requirements reach the team after passing through sales, support, and product, and each hop loses something. By the time it’s a ticket, “our finance team spends Friday afternoons reconciling these numbers by hand” has turned into “add CSV export.”
Hearing the customer directly changes what you build. Read the support tickets. Sit in on a user interview, or on the sales call for the feature you’re about to build. You might find out the CSV export was a workaround, and what the customer wanted all along was for two reports to agree.
Code was never the goal. Solving real problems for real users was, and you can’t solve a problem you’ve only heard about third-hand.
If the software keeps coming out wrong, look at the conversations that produced it before you look at the code.