Ever had one of these conversations?

“Oooh, I hate working with Fred. He's such a negative guy. Every time I come up with an idea, he shoots it down. There's always some reason that it won't work, some obstacle that prevents us from putting it into place. It's like the guy lives to just tear down everybody else's ideas.”

“Well, why not ask your boss to just keep you from pairing with him?”

“Oh, I couldn't do that.”

Sometimes you can't hear advice without thinking of ways it won't work.

But as much as it may be fun to beat on this topic for a while, on the various ways we shoot each other down without even consciously realizing it, there's another aspect to “negativity” that I want to get into: the idea of using “negativity” to help with software designs.

It is said that when Michelangelo finished his masterpiece, the statue of David, the Pope asked him, “Tell me the secret of your genius. How have you created the statue of David, the masterpiece of all masterpieces?”

Michelangelo's answer: “It was simple. I removed everything that was not David.”

Recently, I've become more deeply embroiled in the startup world - six months ago, as the CTO for a fledgling e-commerce startup, and then more recently, as the CTO for a consulting services shop. As such, I've been attending lots of meetings by and for the startup community, and usually the presentation is by an “industry veteran,” a startup founder who made it work. When asked the secret of their success, there's always an answer. Whether it's “keep it lean,” “validate your product,” “don't think about scale,” or “always think about scale,” the answers are pretty much all over the map, and in some cases entirely contradictory.

This has led to my conclusion about startups: We have no freaking clue why one startup succeeds and another one fails. We can't pinpoint exactly what makes a given business model succeed and another fail, except after the fact and with the benefit of hindsight. “Of course Google succeeded! They realized that search was what users really wanted!” “No, it was because they had the simplest user interface!” “No, it was because they were Stanford grads!” And so on.

This hasn't stopped people from trying to blindly replicate their success, though. Would-be agile-ists insist that programmers must work in pairs because “that's what agile says you have to do.” Would-be startup founders insist that their first step has to be to find an investor in the idea, because “that's how it's done in Silicon Valley.” Or that you have to work distributed, because “that's what GitHub does.”

The truth is, we don't really know why some start-ups work and others fail. Nobody knows. Formulas and policies that worked for some companies fail for others, and vice versa. We know a bunch of things that make companies fail pretty quickly, but we still, after almost two decades of “Internet startups,” can't predict what makes a company succeed in the long term.

Interestingly enough, this state of affairs isn't a problem. In fact, I'd argue that this realization is fundamental to success in programming, career, and life: that negative knowledge (what not to do) is much more potent than positive knowledge (what to do).

Via Negativa

The Greeks and Romans, whom we in Western civilization have this tendency to venerate for their incredible insights into life and living (which we today call “philosophy”), had a name for this kind of knowledge: via negativa, literally, the negative path, the path of renunciation, of exclusion, of reduction. It's a curious idea, that we can see a path not by having to know where we're going, but by knowing where not to go.

Theologians were the first to tread the via negativa. We cannot say what God is; we can only say what God is not. Translated to our industry, that means that we cannot say what causes success; we can only say what prevents it. Therefore, if we avoid those things that prevent success, it follows that success will find us in some way. This is all we need to know.

Think it's a crazy notion? It might be. It certainly runs contrary to the way we normally approach our work and our life, that's for sure. But it's hard to argue with its success - one of the richest men in the world (not Bill Gates, but his buddy Warren Buffett) writes about himself and his partner: “We have not learned how to solve difficult business problems. What we have learned is to avoid them.”

Hmm.

Via Negativa Coding

This is not a normal mode of thinking for developers. Code doesn't exist like marble: there's not something we have to chip away in order to expose the famous Biblical character underneath. It's much more like painting, or writing a novel: the blank canvas stares us in the face, mocking us sometimes, demanding that we put something there. In truth, the mockery comes from within our own minds, but it's all the same. New writers, new painters, new programmers, all face the same basic problem, that of “Where do I start?”

Enter the via negativa. Sure, we could get all metaphysical and say that the developer could consider all the possible lines of code that she could write and discard the ones that aren't appropriate to the task at hand, but frankly, that's kind of a philosophically jerky move.

Let's look at it from a different perspective: Of the various design or language features that could be used, rule out the ones that make no sense. Of the various technologies that could be used, rule out the ones that simply don't apply. Most importantly, of all the various “extensibility” mechanisms that we developers try to shoehorn into a design, on the grounds that “someday we're gonna need this,” say no. Put them in later, when you need them. Did the customer ask for this? Do we see a place where we need this form of extensibility right now? Is this something we're building because we have to, or is it something we're building because we want to? Don't decide what the software design in the ether is, decide what it isn't.

I still remember with great horror, the day I interviewed for a programming gig with a software firm who shall remain nameless. The development director asked if I'd ever heard of design patterns and I replied with an enthusiastic yes. He then reached behind him to pull a well-worn copy of the Gang-of-Four book off the shelf, which excited me. These guys know patterns! This must be a really sharp place to work! He then proceeded to open to the inside front cover of the book, and show it to me as he proclaimed, “We use every single pattern in this book” - and sure enough, next to each pattern description was a big, black check mark. Because, you know, successful software designs use ALL the things. Er, patterns.

The best designs, like the best of a lot of things, are not large and complicated, but small and simple. Blaise Pascal intrinsically knew this when he said, “I would have written you a shorter letter, but I lacked the time.” Writers are routinely told to remove every word that doesn't directly support the story. Painters who spend too much time getting details into the background of their work find that viewers miss the central point of the work.

Ironically, the via negativa intrinsically argues for that very core of agile principles, the “design for today” principle, also known in agile circles as “YAGNI” (You Ain't Gonna Need It).

Via Negativa Coders

Now, the really interesting corollary that goes with this thought process is that Fred, our “negative” guy from the conversation earlier, is actually one of the most helpful people you can have on staff. Think about it: he's already naturally on the via negativa, thinking about how the decisions or thoughts aren't going to work. In a way, he's helping the organization come to a better decision about what the right choice should be, assuming his objections are rooted in some kind of rational thought process and not just because he's a jerk.

But even if he is just a jerk, meet him halfway and praise him for his forward thinking. Sometimes, it's his experience talking, not just a cynical nature. And sometimes, the cynicism is rooted in twenty-five years of consulting in an industry where management adopts a latest technology craze because “That's what <insert wildly successful Internet startup> does!” And then he had to live with the consequences of that idiotic decision.