Angry Little Tree

Back in 2000, when dinosaurs roamed the earth, I worked for a software development shop that packed a secret weapon: a methodology. While other companies wrote mere code, we practiced Code Science™, a homegrown process cribbed from the hot new “Extreme Programming” movement. We had best practices and core principles and ten steps and lean documentation; we wrote tests first and we crafted user stories and we pair programmed. We explained to our customers how much better it was than the old way of doing things, and printed up impressive brochures about the new age of software development it would usher in.

No, seriously, we trademarked it.

In retrospect, of course, it’s clear we were swept up in the excitement of the early days of the Agile movement, and desperate to differentiate ourselves in the tough post-dotcom-crash market. Code Science™ did have some good ideas that helped our teams work through tricky challenges — we weren’t stupid after all, just full of marketing hubris. Despite our best intentions, circumstances eventually made it clear that a magical process couldn’t solve every problem.

Boris and Ray were two hardcore coders who worked on my floor. They were both efficient, opinionated, and enthusiastic about their work. They were both assigned to a new project around the time that Code Science™ was being implemented across the entire company, which meant they’d be pair programming.

For a week or two, the novelty of it kept them both on their best behavior: they were professionals, collaborating in realtime! It was a grand adventure! As the project progressed, however, they began to express… differences of opinion. Every task would turn into an epic battle as the two fought about code style, or tool choice, or loop structure, or pattern preference. They argued, everyone agreed, like an old married couple: first to win, then on principle, and eventually because it’s simply what they did.

It seemed intractable, but against all odds they eventually settled down. A month into the experiment, they seemed to have worked out their differences: the office was quieter, code worked, and I mentioned to Boris that pair programming was a success after all.

“Oh, hell, no,” he replied, glaring over his mug of coffee. “Ray is insane.”

Ray, of course, insisted that Boris was crazy.

They had, despite their differences, figured out a system that worked. Every morning, Ray would come in bright and early at 6am, rewriting Boris’s code until it was to his liking. At noon, Boris would roll in. Like WWII soldiers eyeing each other over the trenches, they’d discuss the critical issues that needed to be completed. Ray would leave, and Boris would work until late in the evening — tearing out Ray’s code, writing his own, and declaring it Done. Every morning, the cycle would begin again.

Both Boris and Ray were great programmers, conscientious workers, and all around smart guys who knew their stuff. They’d worked — together, even! — on other successful projects. Meanwhile, there were other developers around the company having great success with pair programming. For whatever reason, though, Boris and Ray’s pairing just wasn’t meant to be.

There are quite a few lessons I could’ve taken away from that episode, but the one that stuck was simple: the amazing powers of magical project acceleration that we attributed to our Code Science™ methodology were oversold. While the systems we used to describe our work played a part in our successes and failures, the biggest factors were simpler. The people working the projects, their skills, and their ability to work effectively together were what made the difference. Tools that improved those factors helped us, and those that didn’t were just fluff. In a 2010 blog post titled Agile Bullshit, Pawel Brodzinski summed it up simply: “Different approaches work or fail because of people, not because they are universally good or bad.”

If you’re good at what you do, the day will eventually come when you’re asked to do something terrifying: explain how you do it. Whether you’re a sous chef or a software developer, it’s difficult to translate your own intuitive processes, the hunches and gut-checks you’ve learned to rely on, into systems that other people can use.

When that day arrives, it’s easy to panic: “Wait, I’m supposed to be Someone Who Talks Authoritatively About Stuff? I should have charts and diagrams and four-point systems and maybe even acronyms, or people will think I’m just making it all up!” Carefully defined best practices and impressively-illustrated processes definitely have their place, but the truth is, that’s not where the magic lives.

Document processes because they work for you and help others understand what’s going on. Capture “best practices” because they save you pain and frustration and time. Research what others have discovered because learning from their experiences is good. Share what you’ve figured out so others can benefit — and offer insights you might’ve missed.

And the next time you’re tempted to put on a show and pretend that you’ve invented Code Science™ or Quantum Hosting™ or some other crazy new recipe to solve all the problems, remember the story of Boris and Ray. Do great work, share what you’ve learned, and don’t sweat the trademarked, nine-step methodologies. The humble truths of your real-world perspectives are worth more than a bandolier of silver bullets.