Software Bugs Are Communication Bugs

Published: 2019-02-01

Tagged: thoughts software work

That problems afflicting software projects arise form miscommunication is not a new idea. My mind churned through everything I've learned. Direct experience provided me with depth, but studying the works of others, such as Weinberg, Brooks, Boyd, Rands, Martin, Goldratt, Marquet, Freeman, and Rosenberg, gave me breadth: everything from lean manufacturing, to leadership, project management, and architecting clean code. And still, communication between developers, teams, departments, and clients appears to be the source of all strife. For a person, writing a program is a way of thinking through a problem, and any bugs are just omissions of thought. But writing software as a team takes this simple (not easy![2]) process and turns into a shared hallucination.

Let's take two software components that don't interface well. On the surface, it may look like a problem related to the language, tooling, or platform. Some might look farther and focus on stand-ups or the kanban board. At its root, however, it's a conflict between two brains interfacing together, resulting in low cohesion[0].

Because it's an inevitable part of the development process, we've come up with many tricks to manage it: agile attempts to keep brains on the same track through stand-ups, stories, and estimation. CI/CD shortens feedback loops by exposing bugs quickly and regularly. Linters, TDD, and code reviews are lightweight methods of testing assumptions. This short list, being a mix of organizational and technical solutions, underlines how broad the problem is and how crucial the ability to talk to other people is. It's the oil that keeps different parts from wearing out. Maybe running a linter doesn't seem like it needs all this communication mumbo jumbo, but getting your team on board to reap the full benefits does.