Way behind on book reviews; here are some capsules

I think owing to busyness at work, limited sleep, lack of exercise and similar things, I’ve been way behind on writing book reviews. Rather than wait until I have the time to handle each of them properly, I’m going to summarize as many as I can right here.

  • Doug Henwood, After the New Economy (With thanks to Henry Farrell for recommending this.) The new economy — everyone blessed with thousands of (as it turns out, worthless) stock options, everyone making money off senseless business ventures, everyone a “web designer” — is over, and we’re back to the old economy. Henwood argues convincingly that the new economy was only really lucrative for the small handful of people on top, and that most of us just continued to get screwed: the American economy got a lot better for the rich and not all that much better for the rest of us. This all avoids being a tirade, because the author combines the prose of the pamphleteer with most of the erudition of a scholar. (“Most of” here is a compliment: most people don’t read scholars, and people should read Henwood.)

  • Ken Auletta, Googled: The End of the World As We Know It

    I’d say there are three parts to this book, woven all around one another: first, and most sizably, lots of Ken Auletta being a Google fanboy (see his onstage interview with Google’s Eric Schmidt if you want to see a man keeping just on the respectable side of fawning); second, a rather powerful chunk reminding us of just how completely the Internet has changed the world; and third, some nonsense, of the sort that drives engineers nuts, about how Google’s focus on rationalizing markets means that they may fundamentally lack wisdom.

    The fanboy part I’ll ignore; I should have expected, in any book about popular technologists, that it would coo over its subject. When Auletta steps back and describes just what the Internet has wrought in only about a decade and a half, on the other hand, it’s astonishing. Craigslist killed newspaper classified ads and thereby a large chunk of newspapers’ revenue. Google is in the process of overthrowing traditional advertising. YouTube is how many of us consume television shows now, and Netflix is how we consume movies. Amazon changes how we buy books. iTunes (Napster, really) turned music digital. Google is moving into the cell-phone industry. Their acquisition of YouTube looked at the time like they were purchasing a known massive copyright-infringement platform with the intent of directly challenging intellectual-property law. And on and on. It’s breathtaking.

    Now, part of what makes Google Google in all of this — part of what all of us love watching — is the rationality driving it all. We perceive — and Auletta confirms — that Google approaches any new market, asks “What should this market look like?” and immediately moves to drive out irrationalities. Advertising could be done better, so Google is doing it better. Cell-phone software sucks and doesn’t reflect the computer revolution of the 1980s; Google is building Android to fix that. They see a problem and have the resources to fix it, so they fix it.

    If you’re from one side of C.P. Snow’s “Two Cultures,” and you’re a writer who needs to provoke controversy in a book about Google, you will wag the disciplinary finger at Google here and bemoan their “cold, logical rationality.” It’s a staple of the genre, and I can’t really fault Auletta for it: in writing a book about a tech company, you’re either going to fall into fanboydom or into These Guys Really Should Have Got A Degree In Anthropology So That They Could Understand How Humans Really Are territory; Auletta does both, and does both rather mildly, so I have little to complain about. But in any case, he has to get in his digs: Google’s founders are confused when EPIC objects to algorithmic monitoring of Gmail, according to Auletta because the founders view the world through hyper-rational blinders. This part of the book isn’t really believable, probably because I’m a geek. Humankind has not created very many men who both are prose stylists and who can talk to geeks in their language.

    (Little sidebar from an earlier part of my life. I used to work for a startup that was all about openness when it could afford to be: that is, when the venture-capital funding hadn’t yet dried up. Every month, they’d show the company’s engineers the raw numbers and the bottom line. Then there came a point when maybe they didn’t want to share quite as many numbers with us. When pressed by the engineers in the room, this company’s founder explained, not convincingly, that we geeks would just take those numbers, overreact to them, and get scared. So this was for our own good, you see.

    Turned out that the numbers were really just bad in an objective sense. By the time the company was acquired — because it had a lot of intellectual property, a lot of smart developers, and a world-famous founder — the acquirer bought it by just paying off its substantial debts.

    I’ve taken some lessons from this: 1) that when openness disappears, it’s time to polish off your résumé; 2) that transparency is something that companies keep so long as it’s convenient; and 3) that geeks really do have a great built-in bullshit meter, which entirely derives from that cold, rational, objective viewpoint that Auletta scorns.)

  • E.L. Doctorow, Ragtime

    The only novel I’ve ever encountered that has a detectable meter. On quite a few pages I read it while snapping my fingers. Check out Ta-Nehisi Coates’s excerpt to see what I mean.

    The story centers on one New York family and the intense, exploding world that surrounded them: Harry Houdini escaping from damn near everything; Emma Goldman (whose Living My Life awaits me on my bookshelf) singing the virtues of anarchy and inviting policemen’s truncheons; obsessive men falling prey to the charms of glamorous film actresses; murders happening on the roof of the original Madison Square Garden; and black men resisting abuse and getting torn to shreds as punishment. In its literary skill at combining many historical personages into one fluid story, it’s like Forrest Gump for smart people. This is an exciting, captivating, rhythmic book. My only suggestion would be that you read it in one sitting: the excitement is hypnotic, but only if you’ve let yourself settle into the trance that Doctorow has built for you.

    (Ragtime confirms a pattern I only started to notice when I got into Philip Roth: books by men very often feature completely unexplainable sex by their male protagonists with beautiful women. The men are often awkward nebbishes, yet they end up with curvy, sexually unslakable women. It never makes any sense, but hey: if I get into the position to write a novel, I’ll probably put my fantasies down on paper too. “Maria Romero’s raven-black locks fell around her as she collapsed breathless on the silk-covered pillow. She’d spent the previous six hours engaged in her favorite activity: ecstatic sexual congress combined with a lecture on Löwenheim-Skolem.” Get ready for it, because nerd porn is coming.)

  • Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams

    There’s a lot to recommend this book, and lot to recommend avoiding it. On the plus side, the authors really are on the right of the battle to make companies enjoyable for their workers. Give all your employees windows, they say; it’s nonsense to claim that this is impossible, and hotel rooms — every last one of which has a window — supply the existence proof. And more: don’t push your employees to push crap out the door; let them know that you respect quality, and they will rise to the challenge. And still more: your teams need to “gel” (DeMarco and Lister may spell it “jell,” but I refuse). To make them gel, they need managers, but they don’t need managers to sit watching their every move. Your employees want to create great work; people want to enjoy coming to work every day, and they want to produce something that they’re proud of. Make that kind of job available to them, and the quality product will flow out of them naturally. Hence the quasi-paradoxical line: Quality is free, but you have to pay for it. Peopleware is loaded with good bits like this.

    At the same time, it suffers from some annoyances. The authors seem out to sell their own consultancy, so much of the book feels like hucksterism. Just adopt practices A, B, and C, and you’ll end up with a great company. There’s certainly a selection bias: those companies that enlist DeMarco and Lister’s consulting services probably differ systematically from those that don’t — either in the negative sense that more’s broken at D&L’s clients, or in the positive sense that those clients are the more adaptable ones. D&L insist that they’ve distilled decades of experience into this book, which just makes me crave more evidence that they’ve fomented real, positive change for their clients. Then there’s the inevitable question: if you guys are so good, why haven’t you started a software company?

    So expect about half this book to make you pound the desk with enthusiasm. Expect the other half to make you roll your eyes.

  • Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering

    Everyone in software knows this book by now. It’s most famous for Brooks’s Law: “adding manpower to a late software project makes it later.” Brooks presided over a number of massive projects at IBM in the 60s and 70s. He writes from a whole different world: the technical specs for a new operating system would fill 10 or more feet of bookshelf space; contrary to my expectations, Brooks actually seems happy about that. You just have to get the right documentation guy to write clear docs.

    In some ways, Brooks’s writing sounds really antiquated; it’s written for people putting together massive software projects that take years to complete. All the rage nowadays is “agile”: get something out the door within a few weeks or months, then improve it bit by bit over time. In part this is to control customer expectations: put something concrete and limited before your users; now they have a specific reference point against which they can specify their needs, rather than building a dream world in their minds that you’ll never be able to meet. Brooks’s Law certainly applies as much in this new world as it did in the old. As do Brooks’s other maxims: software still needs a designer to impose architectural harmony on the whole.

    I found his “No Silver Bullet” idea the most compelling of all: that no improvement in software technology or process would improve programmer productivity by 10x over the next decade. Brooks held out some hope for object-oriented programming, but I think his hopes — feeble as they were — have been dashed. The promise and the peril in organizations comes from, and has always come from, the people in those organizations. No amount of technology is going to solve that problem. Brooks summarizes one part of this as Conway’s Law: “Organizations which design systems are constrained to produce systems which are copies of the communications structures of these organizations.” That’s still the truest thing I’ve ever read on software-organization design.

    For how much it’s discussed, I’m amazed that I still got so much out of Brooks. The Mythical Man-Month remains a must-own.

  • Siri Hustvedt, What I Loved

    This is another book that has to be read in few sittings, I think. It’s really an unending series of heartbreaks and frozen daggers to the gut (metaphorically speaking) for the poor narrator. Having read it over many sittings and scattered sessions on the elliptical at the gym, I lost a lot of its rhythm and its beauty. The narrator is a professor at some New York university (possibly NYU, possibly Columbia — I don’t know that the book ever says), his best friend is a mixed-media artist, his best friend’s first wife is a strange, cold woman, and he’s surrounded by a cast of literal misfits. People die suddenly, others get involved in drugs, and the world just keeps dragging him along. His voice has an exhaustion to it, which Hustvedt conveys skillfully: he’s at the end of his life, looking back on one disaster after another.

    Obviously I can’t really suggest such a book for what it will do to your spirits, but it’s an engaging read.

  • Diego Gambetta, Codes of the Underworld: How Criminals Communicate

    Fascinating from start to finish. You can think of many reasons offhand why such a book would be endlessly captivating, but Gambetta will continually surprise you with the twists and turns in his subject.

    Start with the obvious question: you’re a criminal, and you want to communicate with your fellow-bad guys. How do you do it? That’s intriguing on its own. If you know the other bad guy, you can vouch for him (or think you can — see “Brasco, Donnie”). If you don’t know him, you need to much more carefully apply the vetting that we use in the legit world: find someone you know who knows him, ask around about him, and so forth.

    Obviously your big concern as an underworld fellow is the police. They’re constantly trying to listen in on your communications, get fellow bad guys to turn state’s evidence, and plant undercover cops in your midst.

    When your organization reaches a certain level of success and infamy — think of the Mafia here — you now have a brand to protect. Rival organizations start claiming your name to strike fear into their enemies’ hearts. To avoid brand dilution, you need to make sure that only those people who are actually in the Mafia say they’re in the Mafia. Trademark law isn’t going to protect you here, so you need to enforce your own brand.

    And how do your establish your bona fides as a bad guy? One intensely fascinating thread in Codes to the Underworld has to do with commitment strategies: imposing some heavy cost on yourself — some cost that absolutely no one outside the Mafia (or whichever group) would ever think of fakin. Henry Farrell, over at Crooked Timber, excerpts one amazing bit on this score:

    Erefaans face is covered in tattoos. Spit on my grave is tattooed across his forehead; I hate you, Mum etched on his left cheek. The tattoos are an expression of loyalty. The men cut the emblems of their allegiance into their skin. The Number [the name of the hierarchical system in Pollsmoor prison] demands not only that you pledge your oath verbally, but that you are marked, indelibly, for life. Facial tattoos are the ultimate abandonment of all hope for a life outside.

    Gambetta has spent decades studying the Italian mafia. He’s a brilliant economic naturalist, with story upon story from the world out there. He’s a gripping writer, to boot. Codes of the Underworld is one of the few works of economics that you’ll be unable to put down. This may be because it’s not recognizable, at first glance, as a work of economics. But its economic cred is pristine; it’s filled with references to the great Thomas Schelling. Highly recommended, both for those who love economics and those who love The Godfather.

    (I’d be remiss here if I didn’t mention, by the way, Schelling’s Micromotives and Macrobehavior. It’s an boundlessly interesting piece of work.)

Let's not penalize most failure (a riff off Google's Chrome OS)

My friend Jamie notes that, on the basis of what he saw in a demo of Google’s Chrome OS yesterday, it’s going nowhere. I think this is the wrong way to look at it, for two reasons: first, it’s important to get something out there, and second, more generally: we, as a society, overly penalize failure.

Before I start, I should note that I know essentially nothing about the Chrome OS. I haven’t watched any demos of it. I know that it’s a stripped-down OS for use on netbooks. I’ve read John Gruber’s perfectly sensible point that many of us have one primary computer — a laptop or a desktop — along with a telephone (like the iPhone) that looks like a crippled computer if you squint at it right. As Gruber puts it: maybe you don’t need two cars; maybe you just need a car and a bicycle. People get along very well with a car and a bicycle.

My point here has little to do, though, with the substantive claim against Chrome OS. I don’t actually care a bit about the Chrome OS. Jamie links to some pundit’s piece, wherein the pundit claims that Chrome OS is “doom[ed] … to the dustbin of history.” Pundits need to say things like this; their jobs are to be provocative. I think it’s quite silly to take a position like that, however, when the record of pundit prognostication is so poor. Hell, the first version of Google’s Android phone interested approximately no one. Compared to the iPhone, the G1 was a flop. We’re on to the Droid, now, which people really seem to love. To suggest that the Chrome OS is dead on arrival is to suggest that it won’t improve. Windows 1.0, anyone?

Which gets to my real point, which is that you have to start somewhere. What I’ve learned from working at a startup, and from reading Stealing MySpace, is that it’s far better to get something out there, essentially no matter how broken it is, than to take forever to produce something stellar. A few reasons:

  1. By setting a firm, soon-to-arrive release date for a product, you force yourself to get something done. As they say: If it weren’t for the last minute, nothing would happen. Get something out there, then improve it.

  2. By offering a real, tangible product, you give your customers or potential customers a basis for criticism and comment. Now instead of dreaming about an ideal Google OS that they can attach all their hopes and dreams to, people have the real thing in front of them and can ask for specific improvements. (This is a point that lies somewhere within The Mythical Man-Month, which I need to review.)

    There’s a related point in here, by the way, about how to manage software organizations: if you design in a vacuum, with no actual customers to examine your product, you’re going to build something that no one wants. If you design for one customer, you’re going to find that the second customer wants something different from the first and you’ll need to redesign anyway. The Mythical Man-Month argues that you’re going to throw away your first design anyway, so don’t bother over-designing it. All of which suggests that if Chrome OS is undercooked — and again, I don’t know whether it is, and don’t care — that’s exactly as it should be.

  3. I’ll argue this next point by way of an example from my own life. I had been considering upgrading my iPhone to the latest, greatest, highest-capacity version from the 8-gig 3G I have now. Google’s Droid and Palm’s Pre aren’t good enough yet, so far as I can tell, to make me switch away from the iPhone, but they are making me delay my upgrade decision. Maybe there aren’t any phones I want to upgrade to right now, but do I want to lock myself into another two-year AT&T contract when Google or Palm might produce something really stellar before that contract would expire?

    Maybe the Chrome OS isn’t good enough to sway many purchasing decisions right now, but it’s out there now and will probably improve over time. As it does so, it may drive a wedge into the market: people will hold off until they see what Chrome OS 2.0 or 3.0 is all about. This is the strategy that Microsoft — and, I presume, most any smart software company — has been using for years; it’s called “vaporware” when a rival is doing it, “good marketing” when you’re doing it. Chrome OS may be strategic vaporware, and Google would be entirely right to create such a thing.

  4. There’s also the notion of a “disruptive technology.” I’m told that The Innovator’s Dilemma has noticed a classic pattern with certain technologies; here I find MySQL a convenient example to keep in mind, though it breaks down when Sun buys MySQL and Oracle buys Sun. The pattern goes like this: there’s some entrenched player (think Oracle) that makes a massive, hardened, massively supported behemoth of a product that people pay premium prices for. Then along comes the little guy, producing a product that is — from the big player’s perspective — crippled and puny and not worth worrying about. Even better from the big player’s perspective, the little guy appeals to the big player’s most troublesome customers — those that don’t generate a lot of revenue and that generate a ton of support calls. So the Oracles of the world gladly dispense with their little customers. (Think of MySQL back when it only had MyISAM tables which didn’t guarantee that your data would be there after a power outage, didn’t support foreign-key constraints, and generally only functioned as a fast indexing engine on top of a bare filesystem.)

    Now the little guy has some customers. They’re little customers, but they’re customers. So now the little guy can build a product based on feedback — which it happily and quickly does, because there isn’t much code to change or much of an organizational battleship to turn. So now the little guy improves his product a bit and shaves off a little more of the big guy’s customers. The big guy still doesn’t notice; the little guy remains beneath his radar. Bit by bit, the little guy cuts into the big guy’s market; by the time the big guy notices, it’s too late.

    We’ve been thinking about Defeating Microsoft Windows for a very long time. It’s pretty clear to me, by now, that that’s just the wrong way to think about it. If I had to wager, I would suspect the Chrome OS is Google’s way of acknowledging that that’s the wrong way to think about it. Google isn’t going to destroy Windows with the Chrome OS, but maybe they’ll take a little bit away from the low end of the market. They probably won’t defeat IE with their Chrome browser, but they’ll insert a little wedge in that market; whatever happens, Google cannot be locked out of the browser market. Microsoft may lose a few customers here and there who decide that they don’t need a desktop computer and can do all they need with a browser, an email client, and a mobile phone. Little by little, companies pick off little corners of the computer market. Maybe Microsoft learns how to respond to these: maybe Windows Mobile goes somewhere; maybe IE becomes a capable browser; or maybe it doesn’t. But the point is that the direct assault on Windows has been tried and has failed. One promising approach to defeating Microsoft is to attack indirectly.

For all these reasons, even if Chrome OS is a failure, it may be valuable. As a society, we take a hard line on failure. We venerate Apple and excoriate Xerox. We praise Facebook and condemn Friendster. In the intellectual realm, I’ve seen praise of Gödel and condemnation of Bertrand Russell. In some senses it’s just that we do so; in many others, it’s not. Each generation of an idea learns from the failures that preceded it. The generation that succeeds generally could not have known where to step had it not watched the missteps of preceding, failing generations. We know that Newton succeeded by standing on the shoulders of giants, but don’t always realize that they were giant failures. And we’re better because they were.

The truest statement I've ever read about software-organization design

From Fred Brooks’s The Mythical Man-Month, which labels it “Conway’s Law”:

“Organizations which design systems are constrained to produce systems which are copies of the communications structures of these organizations.”

(This turns out to be a quote from Mel Conway’s essay “How Do Committees Invent?” It appears slightly differently in that article. Brooks’s stylistic editing was a good idea.)

I could come up with at least a dozen examples from my own work experience that confirm Conway’s Law. Indeed, I’m glad to find that I’m not the only one who’s had this idea.

Maybe the best example of this failure is when one group within a software organization considers a certain kind of work distasteful, and thereby throws it over the wall to another group to handle. Imagine, for instance, if engineering finds deployment odious, and hands that task off to a deployment group. The deployment group must then behave as though it were independent of engineering; it gets limited input from the engineers. The classic pattern here, then, is for the deployment group to write code that protects against any of the bugs from engineering. Layer upon layer of protective wrapper scripts then form around the engineering nucleus. The code, then, mimics the structure of the organization — whereas if the groups had been working together from the start, the code would reflect deployment concerns at a much earlier point.

If we’re going to ascribe laws to people, I’d like to posit Laniel’s Law: there are few genuine technical problems within a software organization, in the sense of problems that can be solved by a faster algorithm or more hardware; there are only employee or structural problems manifesting as problems in code. Come to think of it, this is basically a restatement (in more-pessimistic form) of Conway’s Law.