I take it all back! Send me your money!
Author's Note, written (shortly) after this entry — I'll spare you the suspense: today's post is crap! It's partly just a "hello, I'm still alive" ping, and partly an effort to close out some of the topics I opened recently, so I can move on to new things. And it does poorly at both. But I've been insanely busy at work for the past 2 months, and I wanted to get one more post in before the end of the year, so there's been no good time for it. We just recovered from a 3-day power outage in Kirkland after a nasty windstorm, so before diving back into work, I figured I'd throw these thoughts out, jumbled as they are. There's nothing new here, though.
After reading the first couple of comments, I've decided that my next few blogs will almost certainly be about Emacs hacking, since I've done a ton of that on the side lately. It's fun to talk about, and yields lots of prettily-colored code. So after the first of the year, look for some Emacs stuff from me.
Rumor has it that I've been eaten by Godzilla. There's a fat-joke in there somewhere, my gut tells me. Ahem. There's also apparently a rumor that I was abducted by the Agile Mafia, as if they were somehow competent enough to get past their standing morning meetings and do something about me. And there's evidently speculation that Google got mad at me for exposing how cool they were, and they locked me in a room filled with doughnuts and are forcing me to eat them all.
That last one is -almost- true, except the part about the lock on the door. They know all they need is the doughnuts.
Anyway, I figure I'd better write something before Godzilla really does eat me. Lord knows all this Google food is turning me into a target even Gojira-sama might notice.
I don't know what I'll end up writing about today, but let's start with my blog anniversary, shall we?
One-Year Blog-O'-Versary
Almost exactly a year ago (give or take a couple days), my buddy and fellow Googler Sean O'Connor was walking over to invite me to play foosball on our crappy old table, as we often did, when he mentioned in passing: "hey man, I read your blog".
"Sorry, which blog is that?" I hadn't blogged anything to my internal Google blog in a while, but I assumed that's what he meant.
"The one about Emacs".
That was just weird. I hadn't written anything about Emacs since back at the 'zon. What was weirder was that he was the third person that week to mention a blog entry of mine, which had never happened in my six-month tenure at Google, and each person had mentioned a different old Amazon entry.
A little investigation turned up that there was this spiffy new-ish user-posted news site called Reddit, a PG-startup site no less, and a bunch of my old Amazon internal blogs had been showing up there that week. Which was odd, because I had put them online fully six months earlier and then forgotten all about them. Why were they popping up now, all at once?
For lack of a better term, I'll call this phenomenon Essay Molasses. If you know what it's really called, please enlighten me. I wrote about it in my You Should Write Blogs essay back at Amazon, describing an essay my good friend Jacob Gabrielson had written (still Amazon proprietary info, alas, though it wouldn't hurt them to publish it now.) Almost nobody read it initially, to my considerable dismay, but after six or eight months its key ideas had mysteriously spread to virtually everyone with decision-making power in the company.
Essay Molasses is a time-delay on a meme that would otherwise spread rapidly, but because the idea is encoded in an essay from a relatively unknown author, most people aren't going to read it until it seems everyone else has read it. Like anything else, the growth rate is effectively exponential, so by the time you hear about it, it seems to have appeared overnight. But its initial readership is measured in days (or weeks) per person, rather than persons per day. By the time you hear about it, it may have been around for quite some time.
Based on my two data points — Jacob's essay and my Amazon blogs — I could conjecture that the time delay is about six to eight months. But I'm sure it's a function of context, and content. How long was it before Hardy noticed Ramanujan, or Einstein paid attention to Bose? (Not that anything I or Jacob have written is nearly so original nor valuable, of course, but I figured I'd pick some examples of Essay Molasses that you've actually heard about.)
Although I don't have anything resembling conclusive evidence, I think Essay Molasses is closely tied to the survival of the idea. It's a gestation period, and if you take away the essay that wraps the idea, the embryo won't survive. People accuse me of being long-winded, but it's not often that breaking short wind, amusing as it can be, has any real long-term effect.
I could use a good marketing name for this longer-is-better phenomenon too. The synopsis is that I think taking the time to write about something thoroughly gives it a greater (if slower) impact. Look at Gladwell's "The Tipping Point," or Surowiecki's "The Wisdom of Crowds." Either of their theses could have been succinctly expressed in a simple essay or paper, but would they have had the same global impact? I think not.
With respect to blogging and essays, researching your idea a bit is helpful, sure, but even just thinking about it carefully can often provide that nourishing yolk that gets your idea past the chicken-and-egg adoption phase and into the mainstream, where people can whine about how much they dislike you on Reddit. Ah, sweet, sweet success.
And taking too long to research it can effectively kill it. I've been blocked many times by the desire to turn an idea into a more formal thesis, when all I really needed to effect change was to get the idea out there. People are smart, and they'll figure out the remaining details (and omissions or errors on your part) quickly enough once you've got your basic idea across. So call it laziness, call it long-windedness, call it sloppy pseudo-journalism, but I'm writing the way I do because I suspect it yields the best ratio of effort to impact. Feel free to be your own judge!
So, after that six-month pregnant pause last year, my Amazon blogs burst out last December like a sudden, fierce, smelly wind, blowing everyone's hair back and causing mere candles to flame like war-torches. And I've emitted occasional new outbursts ever since.
The problem is that once you've said one or two things that are tolerably credible, everything else you write gets immediate attention, with no molasses anywhere in sight, and if you say something stupid it will be all over the place in no time. So it can be a little scary writing anything at all. It's no wonder people are so slow to publish research papers; they have to cover their arses tenfold, and hem and haw with the approriate disclamatory rituals to minimize the risk of being found wrong on some point, to their supposed perpetual embarrassment.
Of course Ramanujan was wrong about a lot of his theorems, and it doesn't mar his genius in the slightest. But most people would rather be right about something trivial, or simply not be heard at all, than be wrong occasionally in the quest to get their ideas out to others.
OK, I've said way too much on Essay Molasses. Presumably the lessons here are: (1) say what's on your mind, and don't worry overly much about being right or wrong or you'll delay the flow of ideas; (2) don't expect anyone to read your work until sufficient Essay Molasses has flowed slowly under the bridge, and (3) take some time to tell the whole tale. Even if people don't care for the destination, they might possibly enjoy the journey.
Agile Postscript
I've been thinking of writing some sort of Grand Finale to what would then become my Agile Trilogy, but none of my ruminations have really jelled into any, ah... any jelly worth... er, ruminating. *Cough* So rather than trying to make them pretty, I'll just dump my ideas on you in the buff. They're flitting around in my head like, oh, a bit like healing fairies from any Zelda game, if you really must know where I'd rather be right now, and I'm going to snatch them in mid-flight and put them in little jars for you to gawk at.
You can really tell when the wine gets ahead of the writing. I'm telling you.
First, I was going to write an earnest little memo from Karl Marx, written to Josef Stalin and Mao Tse Tung, along these lines:
Wouldn't that have been cute? Nah, you're right. Stupid. Plus, I kinda have a soft spot for Fowler on account of his Refactoring book (you know, the one none of you IntelliJ users actually read), so I'd have reservations about poking fun at him in public, even if he'd said something really dumb.
Next, I was thinking of responding individually to each of the 10 trillion comments I got on my last 2 blog entries, like so:
Commenter: Entertaining rant, but you just don't get it! Agile works for me, so it Must Be True.
Me: I take it all back! Give me your money! Oh, God, what have I done? Is it too late for me to get away with becoming a Feng Shui consultant? I had no idea how much money you can make by exploiting the credulous. Seriously. Had I only known... ohhhh, the pain... But given that I've pretty effectively excluded Agile Consulting from my agenda, how far afield must I reach before my balls are safe?
Commenter: Great post! It's the best!! If you've got a moment, please drop by http://www.i-beat-captcha.com and find out all about my spam thingy. Made it myself!!
Me: Mmmmmm.... Spaaaaammmmmm....
But I'm too lazy to respond to all of them personally. So, you know, just send all your disposable income to an Agile Consultant near you. Any one of them will do just fine. They all say the same thing: "You don't quiiiiiite get it yet. Cha-ching!"
NEXT, I was going to reflect on how I don't like ceremonies. Yeah. Seems unrelated, I know. But Agile, being a church and all, is big into ceremony and ritual. You'd think ceremony would kinda get in the way of actually getting real work done, but they'll tell you otherwise. So they get this aging bald guy to cut a big ribbon in front of the new mall... damn, I'm sorry. My bad, I've got the wrong ritual. They get an aging agile consultant to steep your team in all the latest stand-up rituals, including the all-important Passing the Hat ritual.
I'm not big into ceremony. I've known this for many, many years, since I was a wee youngun on my way to First Communion, and my intense dislike was deeply reinforced during my long tour in the heavily ceremony-laden U.S. Navy. I don't like dressing up. I don't even particularly care for the Two Big Ones: weddings and funerals. I can deeply appreciate receptions and wakes, since they're much less rehearsed, and peoples' true feelings tend to display. But ceremonies, where we all dress up and hold hands and mouth the expected mouthings, they're just not for me.
Maybe they're for you. If so, we differ, and I can respect that. Most people like their ceremonies; they think they're one of the things that separates from animals. Not true, of course; I've seen hippos and crocodiles performing the most amazing and heart-rending death-rituals on Discovery Channel. But ceremonies make people feel like, you know, life's all important and meaningful, and that big green mall-ribbon somehow imparts depth to an otherwise shallow and trivial historical event.
Not for me. And I see a clear connection between Agile, with its stand-up meetings and its status reports and its hokey project management artifacts, and the desperate need for ceremony. To me, ceremony is necessarily phony. Real ceremonies are unrehearsed, impromptu gatherings in which the participants stand momentarily in awe of the amazing events in which they are (almost always unexpectedly) partaking. Such occurrences happen once and only once per event. Spare me the Mall Grand Opening Guy.
FINALLY, in my third big Agile Installment, I was planning to demonstrate to all interested parties that Agile is simply about recycling tired ideas, nothing more. The Agile folks are entirely concerned with being able to predictably replicate shit that other people have already delivered: it's just the Church of Me-Too.
This last point seems pretty obvious, if you stop to think at all about it for a moment. Do we have Agile Modern Art, in which teams gather to predict how many days it will take to produce the next modern masterpiece? Do we have Agile Great American Novelists getting together in little self-help meetings to talk about how Operations Research can help them write the next Da Vinci Code? (You can just smell the jealousy on them, too. How did such a crap novel make it so big? A hundred thousand prospective Agile Authors have been asking themselves that since it farted itself into the public consciousness. Oh you can bet your sweet b-hind that I'm jealous. At least I admit it!)
The answer to all these rhetorical questions, is, of course: "eight?" (If you're a Simpsons fan, anyway. "Do I know what a rhetorical question is?" --Homer, in quite possibly the Best Line Ever.)
You can't predict the delivery or quality of great art, unless maybe you consider Thomas Kinkade to be Great Art. You can't predict the next Mark Twain or the next Douglas Hofstadter, and no amount of stand-up-meetingism is going to produce one for you. Index cards surely will not. But prediction is what half the Agile folks claim to stand for. Ah, prediction. How we look to our psychics, our soothsayers, our bookies. Now, yesterday, tomorrow, forever. We all yearn for prediction. But when you fall for that crap, you've fallen, like a star from the sky.
I predict that I won't last another glass of wine at this rate, so perhaps I should begin meandering towards a wrap-up.
It seems pretty clear to me, on reflection, that Agile is really all about being able to predict and manage the delivery of stuff that others have delivered. The same old tired websites, the same old inventory-management systems, the same old database-driven doohickeys that the consultants in question have seen a hundred times before.
That's fine and dandy. Wonderful, in fact. As long as someone else does it. You? Fine. Go for it. But I'm going to close this blog with a little belief of mine, one that you're most welcome and encouraged to disagree with, although it won't dissuade me in the least. Let's get to it, shall we?
The Silver Keyboard
In his Mythical Man-Month essay, Fred Brooks Jr. argues that our attitude towards software project management derives from our folklore, in which people cried out for a silver bullet to slay werewolves. But so far there's been no silver bullet: no single, magical, overnight 10x productivity gain.
So when you meet a werewolf: some project or task you're saddled with that threatens your livelihood, what can you do? Lacking a silver bullet, all you have is your own two hands. You grab your silver keyboard and start bashing away. That is to say, you roll up your sleeves and you do the work.
If your boss is a jerk, fire your boss. That much, I hope, is obvious. When I first wrote about software development at Google, most people wrote me and said "you pegged it." But a few people mailed me privately and said: "which Google do you work for? Because it's not like that for me at all!" The answer is: Google is what you make of it, for yourself. If your boss is a vampire, fire him or her! Google can't (and shouldn't) police every last nook and cranny of its own development organization. You need to make sure your group is Googley. And you know exactly what that means, so if it's not that way now, fix it!
And if you're not at Google, which many of you brilliant engineers out there are not, you still know what Googley means! It's the opposite of "sucky". If your organization or team or little cubicle cul-de-sac is un-Googley, then fix it! Googliness needn't be constrained to Google, however prevalent it might be there today.
But how? I mean, do you have that kind of power? You're just a peon like me, right? How can you fire your boss? Or for that matter, if your boss totally rocks in an unrecognized way, how do you promote your boss?
The answer is that you need to be confident. Agile consultants are on the lookout for weakness. If they espy it in you, they'll pounce! And you may not be strong enough to withstand their Agiley claims. I wouldn't have been, fifteen or twenty years ago.
But there's an out for you — for all of us: if you're a superstar, then your management chain needs you. They want the best for you, and if for some reason they don't, or they just don't understand how valuable you are, then they're doomed. Which means "screwed," in modern terminology.
So how do you make yourself a superstar? Never stop learning. I've heard people say they think this position is a crock, that it's ludicrous, that you couldn't possibly spend your whole career learning new things.
But I think differently. I think every program you write should be the hardest you've ever written. And that's what I blog about, mostly. Improving yourself. Because most employers, the ones who matter in the long run, they'll be able to see how great you've become, and they'll alter the very course of their business plan, if necessary, to make the best use of you. Does that sound incredible? Well, I've seen it play out both ways over my modest 20 years in our industry, and that's how I see it.
And that's my little belief. You're welcome to regard it or disregard it as you see fit. But I call my own shots. And even now, after I've found an employer who surrounds me with almost terrifyingly brilliant people, people far greater than I am in virtually any technical dimension you care to name, I can still tell, and tell them, when they've gone astray, and they listen. (Fortunately they rarely stray, and I'm still learning a ton from them every day. The benefit of working for Google, at this point, is still mostly mine.)
And it's a wrap!
My next few blogs, I think, will be about how to make yourself an engineer who's above the Agile Treadmill, who can call your own shots, do your own startup, whatever you see fit.
But I haven't been blogging for a reason. Well, actually a few. One is that I still feel a pressing need to earn my keep at Google, and I've been working like a demon possessed on a new framework of my own devising that I think will more than adequately pay my way for the past year here. Another is that I have an obligation to get my computer game, Wyvern, back online: an obligation to some 50,000 players (out of 250,000 who've tried the game) that I dursn't easily turn my back on. Plus I have some pretty cool stuff in store there, for you Wyverneers who may be listening. Once I get this Google project reasonably secured, that is.
And I do take my own advice: I read voraciously, and I spend as much time bettering myself as I can possibly muster. It's paid off so far, so I see no reason it shouldn't continue to do so.
But these past four hours are all I can afford towards blogging this quarter, so it'll have to do! Hopefully I've quelled any concerns (or hopes) that I've been eaten by Godzilla. And I'll see you all in the New Year, blogging afresh about fresh new topics, God willing.
Happy holidays, and Happy New Year!
p.s. We have 2 Tornado foosball tables in the Google Kirkland Office now. Amazing what just one short year can witness...
After reading the first couple of comments, I've decided that my next few blogs will almost certainly be about Emacs hacking, since I've done a ton of that on the side lately. It's fun to talk about, and yields lots of prettily-colored code. So after the first of the year, look for some Emacs stuff from me.
Rumor has it that I've been eaten by Godzilla. There's a fat-joke in there somewhere, my gut tells me. Ahem. There's also apparently a rumor that I was abducted by the Agile Mafia, as if they were somehow competent enough to get past their standing morning meetings and do something about me. And there's evidently speculation that Google got mad at me for exposing how cool they were, and they locked me in a room filled with doughnuts and are forcing me to eat them all.
That last one is -almost- true, except the part about the lock on the door. They know all they need is the doughnuts.
Anyway, I figure I'd better write something before Godzilla really does eat me. Lord knows all this Google food is turning me into a target even Gojira-sama might notice.
I don't know what I'll end up writing about today, but let's start with my blog anniversary, shall we?
One-Year Blog-O'-Versary
Almost exactly a year ago (give or take a couple days), my buddy and fellow Googler Sean O'Connor was walking over to invite me to play foosball on our crappy old table, as we often did, when he mentioned in passing: "hey man, I read your blog".
"Sorry, which blog is that?" I hadn't blogged anything to my internal Google blog in a while, but I assumed that's what he meant.
"The one about Emacs".
That was just weird. I hadn't written anything about Emacs since back at the 'zon. What was weirder was that he was the third person that week to mention a blog entry of mine, which had never happened in my six-month tenure at Google, and each person had mentioned a different old Amazon entry.
A little investigation turned up that there was this spiffy new-ish user-posted news site called Reddit, a PG-startup site no less, and a bunch of my old Amazon internal blogs had been showing up there that week. Which was odd, because I had put them online fully six months earlier and then forgotten all about them. Why were they popping up now, all at once?
For lack of a better term, I'll call this phenomenon Essay Molasses. If you know what it's really called, please enlighten me. I wrote about it in my You Should Write Blogs essay back at Amazon, describing an essay my good friend Jacob Gabrielson had written (still Amazon proprietary info, alas, though it wouldn't hurt them to publish it now.) Almost nobody read it initially, to my considerable dismay, but after six or eight months its key ideas had mysteriously spread to virtually everyone with decision-making power in the company.
Essay Molasses is a time-delay on a meme that would otherwise spread rapidly, but because the idea is encoded in an essay from a relatively unknown author, most people aren't going to read it until it seems everyone else has read it. Like anything else, the growth rate is effectively exponential, so by the time you hear about it, it seems to have appeared overnight. But its initial readership is measured in days (or weeks) per person, rather than persons per day. By the time you hear about it, it may have been around for quite some time.
Based on my two data points — Jacob's essay and my Amazon blogs — I could conjecture that the time delay is about six to eight months. But I'm sure it's a function of context, and content. How long was it before Hardy noticed Ramanujan, or Einstein paid attention to Bose? (Not that anything I or Jacob have written is nearly so original nor valuable, of course, but I figured I'd pick some examples of Essay Molasses that you've actually heard about.)
Although I don't have anything resembling conclusive evidence, I think Essay Molasses is closely tied to the survival of the idea. It's a gestation period, and if you take away the essay that wraps the idea, the embryo won't survive. People accuse me of being long-winded, but it's not often that breaking short wind, amusing as it can be, has any real long-term effect.
I could use a good marketing name for this longer-is-better phenomenon too. The synopsis is that I think taking the time to write about something thoroughly gives it a greater (if slower) impact. Look at Gladwell's "The Tipping Point," or Surowiecki's "The Wisdom of Crowds." Either of their theses could have been succinctly expressed in a simple essay or paper, but would they have had the same global impact? I think not.
With respect to blogging and essays, researching your idea a bit is helpful, sure, but even just thinking about it carefully can often provide that nourishing yolk that gets your idea past the chicken-and-egg adoption phase and into the mainstream, where people can whine about how much they dislike you on Reddit. Ah, sweet, sweet success.
And taking too long to research it can effectively kill it. I've been blocked many times by the desire to turn an idea into a more formal thesis, when all I really needed to effect change was to get the idea out there. People are smart, and they'll figure out the remaining details (and omissions or errors on your part) quickly enough once you've got your basic idea across. So call it laziness, call it long-windedness, call it sloppy pseudo-journalism, but I'm writing the way I do because I suspect it yields the best ratio of effort to impact. Feel free to be your own judge!
So, after that six-month pregnant pause last year, my Amazon blogs burst out last December like a sudden, fierce, smelly wind, blowing everyone's hair back and causing mere candles to flame like war-torches. And I've emitted occasional new outbursts ever since.
The problem is that once you've said one or two things that are tolerably credible, everything else you write gets immediate attention, with no molasses anywhere in sight, and if you say something stupid it will be all over the place in no time. So it can be a little scary writing anything at all. It's no wonder people are so slow to publish research papers; they have to cover their arses tenfold, and hem and haw with the approriate disclamatory rituals to minimize the risk of being found wrong on some point, to their supposed perpetual embarrassment.
Of course Ramanujan was wrong about a lot of his theorems, and it doesn't mar his genius in the slightest. But most people would rather be right about something trivial, or simply not be heard at all, than be wrong occasionally in the quest to get their ideas out to others.
OK, I've said way too much on Essay Molasses. Presumably the lessons here are: (1) say what's on your mind, and don't worry overly much about being right or wrong or you'll delay the flow of ideas; (2) don't expect anyone to read your work until sufficient Essay Molasses has flowed slowly under the bridge, and (3) take some time to tell the whole tale. Even if people don't care for the destination, they might possibly enjoy the journey.
Agile Postscript
I've been thinking of writing some sort of Grand Finale to what would then become my Agile Trilogy, but none of my ruminations have really jelled into any, ah... any jelly worth... er, ruminating. *Cough* So rather than trying to make them pretty, I'll just dump my ideas on you in the buff. They're flitting around in my head like, oh, a bit like healing fairies from any Zelda game, if you really must know where I'd rather be right now, and I'm going to snatch them in mid-flight and put them in little jars for you to gawk at.
You can really tell when the wine gets ahead of the writing. I'm telling you.
First, I was going to write an earnest little memo from Karl Marx, written to Josef Stalin and Mao Tse Tung, along these lines:
Memo: Communist Imposition
To: Josef Stalin, Mao Zedong
From: Karl Marx
Dear esteemed General Secretary Stalin and PRC Chairman Mao,
I have lately been surfing the net and have heard alarming rumors to
the effect that certain regimes have been imposing their Communist
processes on the proletariat. I assure you gentlemen that this
behavior is one hundred percent at odds with the core principles of my
Communist Manifesto.
To be sure, introducing Communism does sometimes requires a bit of
counterintuitive bloodshed in overthrowing the bourgeoisie. However,
after the revolution, self-determination should be the rule: citizens
should stop and reflect at regular intervals on how to become more
effective, and adjust their behavior accordingly. These rumors of
enforced adoption of personality cults, violent suppression of
non-Agi, er, I mean non-Communist Party ideas, and the blatant
exploitation of the working class — these are all distortions of
the ideas I set forth in my Manifesto.
Well I say: tsk, tsk. All an educated man can hope for is that
continued patient education will eventually help people understand
what Communism is really about. And I prefer to explain rather than
to kill dissenters.
Yours always,
Karl Marx
Wouldn't that have been cute? Nah, you're right. Stupid. Plus, I kinda have a soft spot for Fowler on account of his Refactoring book (you know, the one none of you IntelliJ users actually read), so I'd have reservations about poking fun at him in public, even if he'd said something really dumb.
Next, I was thinking of responding individually to each of the 10 trillion comments I got on my last 2 blog entries, like so:
Commenter: Entertaining rant, but you just don't get it! Agile works for me, so it Must Be True.
Me: I take it all back! Give me your money! Oh, God, what have I done? Is it too late for me to get away with becoming a Feng Shui consultant? I had no idea how much money you can make by exploiting the credulous. Seriously. Had I only known... ohhhh, the pain... But given that I've pretty effectively excluded Agile Consulting from my agenda, how far afield must I reach before my balls are safe?
Commenter: Great post! It's the best!! If you've got a moment, please drop by http://www.i-beat-captcha.com and find out all about my spam thingy. Made it myself!!
Me: Mmmmmm.... Spaaaaammmmmm....
But I'm too lazy to respond to all of them personally. So, you know, just send all your disposable income to an Agile Consultant near you. Any one of them will do just fine. They all say the same thing: "You don't quiiiiiite get it yet. Cha-ching!"
NEXT, I was going to reflect on how I don't like ceremonies. Yeah. Seems unrelated, I know. But Agile, being a church and all, is big into ceremony and ritual. You'd think ceremony would kinda get in the way of actually getting real work done, but they'll tell you otherwise. So they get this aging bald guy to cut a big ribbon in front of the new mall... damn, I'm sorry. My bad, I've got the wrong ritual. They get an aging agile consultant to steep your team in all the latest stand-up rituals, including the all-important Passing the Hat ritual.
I'm not big into ceremony. I've known this for many, many years, since I was a wee youngun on my way to First Communion, and my intense dislike was deeply reinforced during my long tour in the heavily ceremony-laden U.S. Navy. I don't like dressing up. I don't even particularly care for the Two Big Ones: weddings and funerals. I can deeply appreciate receptions and wakes, since they're much less rehearsed, and peoples' true feelings tend to display. But ceremonies, where we all dress up and hold hands and mouth the expected mouthings, they're just not for me.
Maybe they're for you. If so, we differ, and I can respect that. Most people like their ceremonies; they think they're one of the things that separates from animals. Not true, of course; I've seen hippos and crocodiles performing the most amazing and heart-rending death-rituals on Discovery Channel. But ceremonies make people feel like, you know, life's all important and meaningful, and that big green mall-ribbon somehow imparts depth to an otherwise shallow and trivial historical event.
Not for me. And I see a clear connection between Agile, with its stand-up meetings and its status reports and its hokey project management artifacts, and the desperate need for ceremony. To me, ceremony is necessarily phony. Real ceremonies are unrehearsed, impromptu gatherings in which the participants stand momentarily in awe of the amazing events in which they are (almost always unexpectedly) partaking. Such occurrences happen once and only once per event. Spare me the Mall Grand Opening Guy.
FINALLY, in my third big Agile Installment, I was planning to demonstrate to all interested parties that Agile is simply about recycling tired ideas, nothing more. The Agile folks are entirely concerned with being able to predictably replicate shit that other people have already delivered: it's just the Church of Me-Too.
This last point seems pretty obvious, if you stop to think at all about it for a moment. Do we have Agile Modern Art, in which teams gather to predict how many days it will take to produce the next modern masterpiece? Do we have Agile Great American Novelists getting together in little self-help meetings to talk about how Operations Research can help them write the next Da Vinci Code? (You can just smell the jealousy on them, too. How did such a crap novel make it so big? A hundred thousand prospective Agile Authors have been asking themselves that since it farted itself into the public consciousness. Oh you can bet your sweet b-hind that I'm jealous. At least I admit it!)
The answer to all these rhetorical questions, is, of course: "eight?" (If you're a Simpsons fan, anyway. "Do I know what a rhetorical question is?" --Homer, in quite possibly the Best Line Ever.)
You can't predict the delivery or quality of great art, unless maybe you consider Thomas Kinkade to be Great Art. You can't predict the next Mark Twain or the next Douglas Hofstadter, and no amount of stand-up-meetingism is going to produce one for you. Index cards surely will not. But prediction is what half the Agile folks claim to stand for. Ah, prediction. How we look to our psychics, our soothsayers, our bookies. Now, yesterday, tomorrow, forever. We all yearn for prediction. But when you fall for that crap, you've fallen, like a star from the sky.
I predict that I won't last another glass of wine at this rate, so perhaps I should begin meandering towards a wrap-up.
It seems pretty clear to me, on reflection, that Agile is really all about being able to predict and manage the delivery of stuff that others have delivered. The same old tired websites, the same old inventory-management systems, the same old database-driven doohickeys that the consultants in question have seen a hundred times before.
That's fine and dandy. Wonderful, in fact. As long as someone else does it. You? Fine. Go for it. But I'm going to close this blog with a little belief of mine, one that you're most welcome and encouraged to disagree with, although it won't dissuade me in the least. Let's get to it, shall we?
The Silver Keyboard
In his Mythical Man-Month essay, Fred Brooks Jr. argues that our attitude towards software project management derives from our folklore, in which people cried out for a silver bullet to slay werewolves. But so far there's been no silver bullet: no single, magical, overnight 10x productivity gain.
So when you meet a werewolf: some project or task you're saddled with that threatens your livelihood, what can you do? Lacking a silver bullet, all you have is your own two hands. You grab your silver keyboard and start bashing away. That is to say, you roll up your sleeves and you do the work.
If your boss is a jerk, fire your boss. That much, I hope, is obvious. When I first wrote about software development at Google, most people wrote me and said "you pegged it." But a few people mailed me privately and said: "which Google do you work for? Because it's not like that for me at all!" The answer is: Google is what you make of it, for yourself. If your boss is a vampire, fire him or her! Google can't (and shouldn't) police every last nook and cranny of its own development organization. You need to make sure your group is Googley. And you know exactly what that means, so if it's not that way now, fix it!
And if you're not at Google, which many of you brilliant engineers out there are not, you still know what Googley means! It's the opposite of "sucky". If your organization or team or little cubicle cul-de-sac is un-Googley, then fix it! Googliness needn't be constrained to Google, however prevalent it might be there today.
But how? I mean, do you have that kind of power? You're just a peon like me, right? How can you fire your boss? Or for that matter, if your boss totally rocks in an unrecognized way, how do you promote your boss?
The answer is that you need to be confident. Agile consultants are on the lookout for weakness. If they espy it in you, they'll pounce! And you may not be strong enough to withstand their Agiley claims. I wouldn't have been, fifteen or twenty years ago.
But there's an out for you — for all of us: if you're a superstar, then your management chain needs you. They want the best for you, and if for some reason they don't, or they just don't understand how valuable you are, then they're doomed. Which means "screwed," in modern terminology.
So how do you make yourself a superstar? Never stop learning. I've heard people say they think this position is a crock, that it's ludicrous, that you couldn't possibly spend your whole career learning new things.
But I think differently. I think every program you write should be the hardest you've ever written. And that's what I blog about, mostly. Improving yourself. Because most employers, the ones who matter in the long run, they'll be able to see how great you've become, and they'll alter the very course of their business plan, if necessary, to make the best use of you. Does that sound incredible? Well, I've seen it play out both ways over my modest 20 years in our industry, and that's how I see it.
And that's my little belief. You're welcome to regard it or disregard it as you see fit. But I call my own shots. And even now, after I've found an employer who surrounds me with almost terrifyingly brilliant people, people far greater than I am in virtually any technical dimension you care to name, I can still tell, and tell them, when they've gone astray, and they listen. (Fortunately they rarely stray, and I'm still learning a ton from them every day. The benefit of working for Google, at this point, is still mostly mine.)
And it's a wrap!
My next few blogs, I think, will be about how to make yourself an engineer who's above the Agile Treadmill, who can call your own shots, do your own startup, whatever you see fit.
But I haven't been blogging for a reason. Well, actually a few. One is that I still feel a pressing need to earn my keep at Google, and I've been working like a demon possessed on a new framework of my own devising that I think will more than adequately pay my way for the past year here. Another is that I have an obligation to get my computer game, Wyvern, back online: an obligation to some 50,000 players (out of 250,000 who've tried the game) that I dursn't easily turn my back on. Plus I have some pretty cool stuff in store there, for you Wyverneers who may be listening. Once I get this Google project reasonably secured, that is.
And I do take my own advice: I read voraciously, and I spend as much time bettering myself as I can possibly muster. It's paid off so far, so I see no reason it shouldn't continue to do so.
But these past four hours are all I can afford towards blogging this quarter, so it'll have to do! Hopefully I've quelled any concerns (or hopes) that I've been eaten by Godzilla. And I'll see you all in the New Year, blogging afresh about fresh new topics, God willing.
Happy holidays, and Happy New Year!
p.s. We have 2 Tornado foosball tables in the Google Kirkland Office now. Amazing what just one short year can witness...
19 Comments:
Welcome back. This comment is actually about your essay on Refactoring but that page doesn't have it's own comments so I'll put it here.
It seems to me that you characterise Refactoring as turning bad code into good code. I think that's missing half the story. Almost all the refactorings are reversible and have opposites. The reason is that good and bad are subjective and are applied to a context. If you applied every refactoring in the book, you'd just be back where you started.
Refactoring is also about making code easier to change. Some code may be good in its original context, but adding some new feature would be easier if it were factored a different way. The refactored code may then be bad in its original context. But that doesn't matter at this point since the purpose isn't to improve the code, but to make it easier to change into the new context. The advantage of automation is in reducing the chances of human error while making changes.
Once you have changed the code (which should be easier due to the refactoring) you can then set about improving the structure for the new context. Again, the automation reduces the chances of introducing an error.
In summary, you take a one step process "changing a working program" and turn it into a 3 step process "refactor", "change", "refactor". Much of the gain comes from the ability to automate the refactoring steps and thus reduce the chances for errors.
One reason this may be less of an issue for a language like Ruby, would be if most changes are easy to make anyway. That is, where code is equally good in the original and new contexts, refactoring is redundant.
So what happened to Wyvern? Cabochon.com has been unavailable for a long time.
I love Emacs now. Because of you. Why don't you give us the whole emacs package? ttest, ekeys and stuff! Please!
No, you have it all wrong, the best quotable Homer is "In this house, we obey the laws of thermodynamics!"
"People accuse me of being long-winded, but it's not often that breaking short wind, amusing as it can be, has any real long-term effect."
Yes, I have noticed this many times among your commenters. It always reminds me of a conversation between Mozart and the emperor of Austria (among others) in the movie Amadeus:
Emperor Joseph II: "My dear young man, don't take it too hard. Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Just cut a few and it will be perfect."
Mozart: "Which few did you have in mind, Majesty?"
'Nuff said.
Hmm, Steve, Paul Graham and Joel Spolsky all seem to have the same prescription for IT nirvana: Be one of the very best, only work with the very best, only hire the very best.
These are all great ideas, but have absolutely nothing to teach us in terms of how to actually do things. It should be obvious that great people in a poor system will outperform poor people in a great system. In fact great people don't need a "system". Systems exist to quantify and make predictable the efforts of average people. And most people are average.
So I think the main point Steve made here could be summed up as, "Great people do great work, and they do it without needing or wanting a formal process."
Don't get me wrong, I wish more people truly valued the people in their organization rather than just paying lip service to it. I think if you can get the right people working on a problem, you don't need to impose so much formal process. But wrapping that advice up in a slam against a specific process that happens to have some current buzz isn't meaningful or useful.
Stevey, could you comment on why you think OCaml isn't fit for server-side usage?
WOOT HAVENT EVEN READ IT BUT IM HAPPY UR FINALLY BACK. WOOOOOOT!!!!!!!
Steve, I think your comments about Agile development are both interesting and wrong.
Every complaint you've listed about Agile development is can be applied to other development styles.
I worked at a place that thought CMM5 was the only way to develop software. We were required to document every function in our code, along with every parameter. Once coding started changing the spec required at minimum of 3 meetings that took over a week to occur.
The net effect was enormously long functions, massive duplication of code and a project that was eventually cancelled.
Coming from that world the ideas of Agile development are a breath of fresh air. I think you need to give the Agile guys a break. Sure Agile development isn't optimal for creating original software. But, considering the sorts of crap methodologies that were about before they showed up, the things they've come up with aren't so bad.
What you have been complaining about is stupid managers, religious zealots, and the really scary mix of the two. But this isn't an Agile thing at all. Agile development just happens to be the current fad among irresponsible managers.
Regarding the zealots, if you've come from a shop that has older heavyweight development processes, Switching to Agile can be an almost religious experience and engenders the same sort of devotion and misguided zealotry.
All your contrasting of Agile to Google development practices was to advocate an even lighter weight development process.
What Agile development and what the consultants are all about is helping management loosen up and let developers do their work. I understand that coming from someplace like Google, Agile stuff seems really heavyweight. But coming from places that are truly heavyweight, Agile development is amazing. What Agile does really well is let the old guard managers have their beloved predictability while saddling the developers with less process related crap.
Stand up meetings seem really wonderful when they are contrasted with hours long status report meetings. Stories are wonderful ways to capture what is different about this app from the five that are almost exactly the same you've done before. And Stories, don't require hundred page long Word documents.
The main complaint I have with Agile development is that it's current popularity has made it become almost meaningless. Much like "object-oriented" lost meaning in the 1990s.
But the ideas that drove Agile are really valuable. Ultimately they are about reducing the "ceremony" in heavy weight development processes. And doing that in a way that lets management feel in control.
Your complaints were about the "ceremony" that agile leaves in place, but fail to acknowledge the "ceremonies" they replaced.
I completely agree with everything you've said about the Agile camp. I'd like to talk about the discipline of Software Engineering in general.
I've been involved in one or more aspects of software life cycle for more than 10 years now and still haven't figured out where the Engineering in software development really comes from. Software Engineering papers, magazines and research journals mostly talk about process and management. Granted that's one aspect of engineering, but Engineering it is not. Reading journals like IEEE Software Engineering I'm convinced that there are legions of researches trying to figure out new ways of winning millions of dollars of grant money. What easier way than to focus on this "soft side" of software development? This is where I compare these researchers to the Agile folks. They have definitely found a much easier path to fame and/or riches.
I must admit I'm not and have never been a practicing professional engineer. However, I did major in both mechanical engineering and computer science. One thing that becomes quite obvious to anyone familiar with both fields is that while engineering is very structured, formal and mathematical, computer science is not. Granted there is a level of mathematics involved in the analysis of algorithms, but that does not constitute the entire realm of CS. The lack of structure leaves a lot up to an individual's skill and intelligence level.
Can CS ever be structured and mathematical? There have been attempts with works around lambda calculus, formal methods, theorem proving etc. to make it so. So far these have pretty much had no adoption in the industry. I won't go into why I feel these have not been well received here. My experience has been that software development is an art whose success greatly depends on the skill level of individuals. Any attempts to quantify are bound to fail as we've seen with a number of approaches and procedures.
Damn you, Yegge!! You got me hooked on emacs, as well!
It's not all your fault - my company is all Linux and emacs talks to gcc and gives me the errors - and I didn't like kDevelop. My only wish for emacs is key bindings that match common software - you don't know how many times I have C-x C-s'd in MSDEV only to blow away a line of code.
I would love it if you would enlighten us with some of your emacs wisdom - I know there are books, but you've got alot of practical insight that I have already found valuable.
Oh, and because of you, I am looking into OCaml and LISP. Curse you for tempting me with the sweet, sweet fruit of knowledge!!
j,
Have you already read Effective Emacs from Steve?
J:
key bindings that match common software
XKeymacs is priceless!
All of what you have written that I have had the ability to read during my day is more than just a good, educational and entertaing read, but something anyone at any level of any company should read and give more than a passing thought upon.
As a manager, I have found that avoiding "Agile" for true agility is not only a good idea but it does, in fact, give the magical production gains that the "Agile" camps claim to give.
And in a moment of frivolity, I bestow upon you the title of IT ninja #2 (because I was given the #1 spot as part of my official job title years ago at a startup ISP).
Hi Steve,
It's an odd thing that you mention your blog cropping up from time to time. I first found your Amazon rants when I was Googling for some non-Emacs-related term (I was a vim user back then). At almost the same time, I found your Google blog, in an unrelated query. For quite a while I was reading both blogs at the same time, without realising they shared the same author. A wee bit later your blog appeared on slashdot. Just now I found your blog linked to from an Emacs page.
I keep on meaning to bookmark your blog, but I don't really see the point any more - I'm scheduled to stumble on your next rant in a few months time, through a random link from a random page listed in a random Google query.
All the best :-)
Colin Horne
Steve, I think it says a lot for you that people are still discussing Wyvern even now and waiting for it. I am one of the 50,000 (Ikasha, lvl 20 human)and have really enjoyed my time with the game. It's incredibly inventive and the community of people seems especially high quality for role playing games. Hope you get the game up and running soon.
Your line, "I could use a good marketing name for this longer-is-better phenomenon" caught my eye. I find on my blog, http://doxspot.blogspot.com, that my entries are longer than on most. That isn't my intention and I do value brevity, but the topics seem to require more. I essentially warn folks about it in my header. I do wonder how much longer-entry blogs inherently limit readers.
Dox O'Ryan
http://doxspot.blogspot.com/
My take is that agile is very well suited for developers with small unit testes.
Hey steve, AKA rhialto, hows it going. I too am one of the anxious 50,000 who are waiting and desperately going on everyday to the internet and typing "cabochon.com" on the url bar and seeing nothing come up after that. So just to let you know that we are all anxiously waiting for you to get the game up and running. Also if there is anything you need feel free to ask, because we all understand your situation and we feel that its our responsibility to help you get this game running. This should not be a burden for you to bear on your hands alone, and thus we all should pitch in. Again thanks for making such an amazing game and lets have it running and keep it running.
Thanks,
from me and the 50,000 players waiting anxiously
<< Home