Being Wrong and the Art of Writing Software
Jan 5 2011

(via utnereader and poptech):

Kathryn Schulz is an expert on being wrong. The journalist and author of “Being Wrong: Adventures in the Margins of Error,” says we make mistakes all the time. The trouble is that often times being wrong feels like being right. What’s more, we’re usually wrong about what it even means to make mistakes—and how it can lead to better ideas.

This talk is probably the best way I could ever hope to explain what it’s like to write software to a layperson, or at least how writing software changes your view of the world and yourself. It’s also a great way to show why agile engineering teams work better than lone cowboy coders.

To write software is to be wrong. It’s not just that computers are anal about syntax, the problem you’re solving is hard, or that the tools to write software suck. The act of converting your abstract ideas into precise working code shows you just how fuzzy and half-assed your idea really was. Like Schulz implores us to do, good programmers take being wrong as feedback on how to be right.

When I first began writing software in high school, I remember spending most of my time convinced I was right and the computer must be wrong. I did silly things like testing whether the computer could properly perform addition, because clearly computers suck at math. But in every case, it was always my code that was wrong. Always. Once I got past thinking I was right and assuming I was wrong, writing software became dramatically easier.

For those of you without time to watch the whole video, Schulz’ closes by providing an optimistic view of being wrong. Being wrong isn’t the problem, she says, the problem is being convinced you’re right. Just like with my programming skills, an internal conviction that you’re right only gets in the way of achieving actual results. You don’t learn from being right, you learn from being wrong.

She implores us all to externalize the way we answer the question of whether we’re right or not, just like a pilot has a co-pilot, an auto-pilot, a control tower, and an array of gauges and metrics to help him know whether he’s flying correctly. Open-source is mentioned, along with democracy, as a system that can take decision-making away from a single person’s conviction that he or she is right.

Which brings me to agile software development, which I think is a better example of Schulz’ ideas than open-source. Agile software development is a set of methodologies for writing software that I believe have one thing in common. They all expect you to be wrong, all the time, and embrace it. Being wrong is fundamental to being agile, since you can’t pivot quickly if you’re not learning quickly, and you only learn by being wrong fast and often.

The most fundamental way any software team decides whether its code is correct or not is by writing tests – code that tests the performance of other code. Agile teams differ in that they write their tests first, before the actual code to test is written. Tests written after code has been written simply echo back the same logic used to write the original code. They are not independent, and therefore the tests don’t really help you externalize your code’s correctness.

Writing tests first is just the opposite. A test-first approach forces you to think about the problem first, uncover all the horrible edge cases, and determine what external criteria prove the code is correct, irrespective of how the code is written. And since the code isn’t even written yet, the tests always begin in a failing state. They only pass when your code is done, and force you to continually run your tests as you write code. This keeps your mind close to the problem at hand, not some internalized sense of completion.

Schulz’ also emphasizes the need for other people to help you find your mistakes. Doubters, adversaries, or just someone with a different approach or background than you. Whether it’s a co-pilot, a rival, or just someone you want to impress, having others around helps us avoid telling ourselves that we’re right. It also exposes us to other, perhaps better ideas.

In this same vein, many agile software teams practice pair-programming. Two people sit at one computer and write software together, just like Schulz’ pilot and his co-pilot. Perhaps because of the stereotype of antisocial hackers, many people find the idea completely odd. Many, if not most, software developers are also horrified at this idea, since they are used to working alone, without anybody or any tests there to point out their mistakes. They think a pair’s job is to sit there and judge you and tell you you’re wrong.

They’re only half right. Your pair’s job is definitely to tell you you’re wrong, but that’s only a problem if you haven’t accepted that you’re wrong all the time. At the end of her talk, Schulz quotes Richard Rorty: “To accept our own fallibility is to embrace ‘the permanent possibility of someone having a better idea.’” Good pairs should live by this quote, since pairing is fundamentally a collaborative, creative experience that exposes you to new ways of thinking, approaches you’d never considered, as well as just a friend to pass the time with. Pairing only becomes nightmarish if you’re pairing with someone too full of themselves to admit their mistakes, or too afraid of being wrong to share their ideas.

Pairing and test-first development are together the core principles I believe form the highest art of software development. Testing alone, even when writing the tests first, can prove whether our hypothetical pilot can correctly land the plane, but they can’t prove to you that he’s landing at the right airport. Similarly, pairing without tests are like a pilot and a co-pilot flying together, but without any gauges to help them correct their shared assumptions. Pairing and testing together prove that your code works as expected, as simply as possible, and solves the right problem.

Fundamental to all agile principles and practices is the assumption that you’re going to be wrong – dead wrong – and you’ll need to develop practices that help you answer the question of whether you’re right or not. I’d highly recommend anybody watch Schulz’ talk, but software developers in particular.