chanson

Robert Scoble, Big Company PR: turning the heat up on the PR kettle

This invisible information sharing network is real interesting. I remember the day when I learned about the “Universal Runtime” which was code name for .NET. I almost got fired for hearing about that six months before it was talked about publicly — someone who was in an Software Design Review told me “this will be a huge deal for software developers” and I used that information to email my own network about it. Someone told someone at Microsoft and I got in trouble cause, not only wasn’t I supposed to know that information at that time, but I just let a huge number of people know about it too.

Naughty, naughty.

That's not contrition for having potentially done serious damage to the business he was a part of. It's just snarkiness. It shows that Scoble doesn't really think he did anything wrong, and that he thinks businesses should just "adjust" to the "new reality" that some people can't be trusted with secrets.

Fortunately, not everyone is a Scoble. Individuals and companies can plans and do work secure in the knowledge that what they're working on won't be leaked to the public before it — the work or the community — is ready.

Seriously, what could have led him to think "I just learned something juicy about my company, I'd better share it with a bunch of people!" was at all acceptable? I'm surprised that was even remotely tolerated at Microsoft. I know a number of other companies — from startups to the Fortune 50 — where it absolutely would not have been tolerated. Not only would he have faced immediate termination, he could even have faced a ruinous lawsuit. And even if he didn't face such serious disciplinary measures, nobody on the inside would have ever trusted him with confidential information again, regardless of how contrite he was. "Scoble? Don't talk to him about anything you don't want the world to know."

Update: An anonymous commenter — who I have no reason to believe isn't Scoble — says:

The incident in question was before I worked at Microosft. It was my job to plan conferences for programmers so it was my job to figure out what was going on in the marketplace. I didn't sign an NDA.

In that case, whoever told shared the information with Scoble was breaking their NDA, not him. That still doesn't mean it was OK for him to turn around and spread it, if he had reason to believe the information was obtained in violation of an NDA or otherwise obtained illegitimately; trade secrets are still trade secrets.

Bruce Eckel, Programming as Typing:

I think the problem is that while many programmers understand that programming happens in the mind, and the code itself is just an artifact of the process, outside the field, the code looks like it's what you're doing. (An understandable perception, since the code is the core deliverable). So if it's about the code and not the mental process behind the code, it makes sense that you would do whatever you can to produce the code as fast and as cheaply as possible, and to discard anything that appears to hinder the creation of code. From this follows the logical ideas that coding is typing, so you want to see people typing all the time, and that 10 people can type faster than one person so if you can hire ten Indians cheaper than one US programmer, you're going to get a lot more typing done, so you'll get big economic leverage.

This describes exactly the behavior I saw in the contract software development world after the dot-com crash in early 2000. Managers and businesspeople in many organizations thought programmers were just typists and sought a "secretarial pool" model of software development whether within their companies, outsourced, or outsourced offshore.

Of course, anyone who has actually developed software knows that isn't how it works. But in a lot of organizations the people who are making decisions about software development are, unfortunately, not just aren't software developers themselves but have never been software developers. I'm very thankful that I haven't had to deal with anything like that since moving to California.

Keith Ray also has some good comments on Bruce's piece.

If indie musicians were technology startups, every new band for the last couple of years would have a name of the form adjective noun preposition nounified-adjective. And every one of them would use a similar color scheme for their logotype.

Having founded a dot-com startup is makes me qualified to mock the current crop, right? Like, say, 3bubbles?

Darrin Cardani, My Dear John Letter:

Frankly, in the last few years, I've only stayed with you so I could be with Buffy, Angel, Bart and Lisa, and the rest of our circle of friends. However, our tenuous relationship has worn thin.

I won't say you haven't grown at all. You're far less insulting to other cultures. And the advent of motion graphics and inexpensive computer hardware has significantly improved your quality. But you just don't have anything useful to offer me. There was a time when it might have been possible to get some useful information out of you, but not anymore.

And you don't respect my boundaries.

Darrin understands well that markets are conversations since he runs a consulting and product company.

Wesley Bertch, On Location with Life Time Fitness — How Offshore Outsourcing Failed Us, Network Computing:

What are my options if my highly productive, 15-person software team generates only one-third the output our customers demand? I was certain that augmenting our team with offshore development was the right answer. It wasn't, at least for a small project we recently outsourced to an Indian firm. Here's our story.

Plenty of companies have been willing to admit to failures of development projects, but far fewer have been willing to admit to failures of offshore projects. I think this is mostly due to the current fad for offshoring; many companies don't want to be seen as not keeping up with the pack.

I think this is a good sign. It says good things about Life Time Fitness as a company, that a manager there would admit this sort of failure in so visible a fashion. And it says good things about the market, that the fad may be ending and the market starting to settle down. Companies are realizing that they shouldn't care about where they're outsourcing to, but about their overall return on investment of the outsourced projects. Instead of fleeing the United States and Western Europe for India, China, and Eastern Europe, companies should embrace great vendors the world over and leave the mediocre ones to fight over scraps.

And just to make my position absolutely clear to the people who think I'm anti-offshoring: There are companies in at least India and Eastern Europe I think do great Macintosh work. I have no problem as a vendor competing with them, because we're competing on quality of work. The vendors who attempt to compete on price and who don't have the experience to do the work well (though some of them will make big claims about it) are the ones I hate. There are lots of companies like this in India, China, and Eastern Europe. There are also lots of companies like this in the United States and Western Europe. It's a problem all over the planet; neither sending all development elsehwere nor bringing all development here will fix it.

Christopher Koch, Bursting the CMM Hype, CIO Magazine:

The depth and wisdom of the CMM itself is unquestioned by experts on software development. If companies truly adopt it and move up the ladder of levels, they will get better at serving their customers over time, according to anecdotal evidence. But a high CMM level is not a guarantee of quality or performance—only process. It means that the company has created processes for monitoring and managing software development that companies lower on the CMM scale do not have. But it does not necessarily mean those companies are using the processes well.

I thought this article was going to be about "bursting the CMM hype," instead it's mostly about bursing CMM claims. And not claims by or about the CMM, but the claims of some firms to particular CMM levels.

Here are the plain facts: CMM level is not a very good predictor of likely project success and choosing or declining vendors on CMM level is pointless.

There's a little lip service paid to this in the article in the next paragraph:

"Having a higher maturity level significantly reduces the risk over hiring a [company with a lower level], but it does not guarantee anything," says Jay Douglass, director of business development at the SEI. "You can be a Level 5 organization that produces software that might be garbage."

It doesn't address why though.

The CMM claims to to indicate the repeatability and quality of the software process used by a development organization. However, it makes a similar assumption to the IEEE's fatally-flawed Software Engineering Body of Knowledge (SWEBOK) effort: That a waterfall process is The Right Way to develop software, and if we just all follow a waterfall process more strictly and do more work up front and dot more Is and cross more Ts that we'll attain process Nirvana. At that point everyone will have a prescribed role following prescribed tasks, all entirely documented, and software development will truly be a form of manufacturing.

This is a 1950s industrial-management fantasy. It doesn't represent the reality of the successful lean manufacturing world today, and has to my knowledge never been truly representative of successful software development efforts. Today, anyone starting a manufacturing effort needs to study lean manufacturing carefully so they don't make all the same mistakes that were made between 1800 and 1980. And anyone starting a software development effort needs to study agile development so they don't mistake software development for manufacturing, and so they don't repeat the mistakes of 1950-2000.

The CMM isn't all bad. For example, it's been said that a shop that does Extreme Programming rigorously would only need to do a little extra work to qualify for a CMM Level 3 assessment. And XP is actually fairly easy to follow rigorously in some domains when doing new development — sure, it requires discipline, but not tedium such as filling out traceability matrices. But why are there additions necessary to attain Level 3, "Defined Process"? Because CMM doesn't just care that a process is defined but what that process is and how it was arrived at.

For instance, in my company, the process is imposed by fiat: I decide what my company's process is. Period. CMM Level 3 would have me conduct some form of study on process requirements, and then ensure that the process selected meets those requirements, before deciding that I really do have a defined process! In short, CMM requires bureaucracy even though none may be necessary.

The CMM can be useful as a guide in certain circumstances. But if you're going to evaluate vendors against it you should take the time to select what parts of it you care about, understand why you care about them in your particular situation, and then evaluate your potential vendors against those parts that you care about. Theoretically a Level 4 or Level 5 organization will meet your requirements by default, but there may be plenty of shops that have been assessed at lower levels — or haven't been assessed at all — that also meet all of your requirements. As the article says,

There is still no substitute for deep due diligence.

Daniel Howard in Ask Joel - Offshoring:

For example, John Grisham writes best-selling novels about lawyers.  Could he offshore?  Say, he plots out the entire novel, sketches out character bios and writes an example chapter or two.  Then, he ships the whole package off to thirty Indian writers who each write a chapter in a month or two.  Using offshoring, John Grisham could pump out six or so novels a year.  Even if the quality impacts sales a bit, he's going to come out way ahead on gross revenues.  Right?

No, and it is pretty obvious why.

I think the reason why people understand this intuitively with novelists and not with software is that writing a novel is seen as a creative activity, while creating software is seen as a manufacturing activity. Others have written more eloquently than I can about how software development is entirely an R&D activity, so I'll just leave it at that.

There's this myth that it's extremely hard to find good developers. I'll be the first to say that good software developers are pretty rare; you're fighting Sturgeon's Law ("90% of everything is crud") so you always have a lot of people to wade through before you'll find the good ones. But lots of people think it's harder than it is because they're the ones making it hard.

First of all, good developers know we're good. We may not think they're gods — the best developers tend to underrate themselves, because they know what they don't know — but we know we're better than average and have very unique skill sets. If you treat us as if we're interchangeable, we don't like it and we won't like you. This means a couple of things:

1. Don't talk about offshoring around us. Just don't. No matter where they're located, it's laughable that a consulting company on the Big 5 model with hundreds of kids fresh out of a state school is treated as comparable to experts who have many thousands or tens of thousands of hours of keyboard-time behind us.
2. Don't try to rank us against people who aren't our peers. When you're trying to figure out whether a Cocoa developer's bill rate or salary expectation is reasonable, you can't look at rate or salary surveys for all software developers, you have to look at the rates for other Cocoa developers. Same with Java developers, .NET developers, Visual Basic developers, MFC developers... This makes most raw salary survey data pretty useless.

Good developers want control over our lives. There's this law of supply and demand they teach during the first week of any economics course. Basically, it means that the price of a resource is proportional to its scarcity. Good developers are scarce, so we have a higher price. We don't always just want more money. In many cases, we want a choice of where we live and how we work. This means we don't want to live in a podunk town far away from our friends and family just for the dubious privilege of working a fixed set of hours, wearing a tie, and filing reports. If we're not billing hourly, we shouldn't have to bother with timesheets. If we're not in a customer-facing position, we shouldn't have to bother with dress codes. If we're not in meetings all day, we shouldn't have fixed, enforced hours. If we don't have to work with others 100% of the time, we shouldn't have to be on-site 100% of the time. And so on. If you want some of that from us, you have to be prepared to give something up in return, like cash.

Good developers are "intellectual property"-generating machines. I can't stress this enough; this is perhaps the most important point. In everything we do we generate what might be considered "intellectual property." I've had potential employers try to get me to sign away all rights to everything I create, not just what I create as part of my job on the time they're paying me for on the equipment they provide and in the field within which they operate. Uh, I write shell scripts constantly to make my use of my machine easier. Suddenly all those are owned by my employer just because they hired me to do something else? I write tools and utilities to explore new technologies constantly. Suddenly all those are owned by my employer? This is a deal-breaker for good developers. You do not own us, you do not own everything we do, you only own what you pay for — even if you're paying a salary.

If you recognize all of this, and take it into account, you shouldn't have any trouble attracting good developers in any technology. If you don't, you might be complaining that good developers are hard to find but what you really mean is that good developers are too expensive and have too much self-esteem.

There are a lot of people who think service pricing is essentially made up from whole cloth, or that it's easily convertible to the salary of the person who's performing the service. Neither of these are true.

For example, $40/hour sounds "high," right? After all, for a 2000 hour year that's $80,000 — a very respectable annual salary. But it's actually quite a low rate for a highly experienced software developer in the United States.

There's a bit of work in calculating a realistic bill rate for any sort of consulting. Of course you can only charge what the market will bear, and you'll have to take that into account too. But doing some real modeling in a spreadsheet or a program will help you figure out what you need to charge, and where you have room for adjustment.

For a simple example, start with your base salary.  Now tack on 25% as payroll overhead to cover all of the various payroll taxes you'll have to pay. This may be a little high, but it's good to create conservative models. It leaves some room to give, and it also makes it less likely you'll run into unpleasant surprises. (Like, say, losing money even though you're currently billing.)

Now add the rest your expenses.  For example, your software and hardware budget for the year.  Your general and professional liability insurance. Your benefits.  Travel expenses for conferences.  Office rent. Phone and utilities. Training classes.

Then calculate a realistic number for your potential billable hours in a year.  I've come up with 47 weeks a year with 35 billable hours a week, or 1645 hours.  After all, you need some vacation, some sick and personal days, and you can't bill conference attendance or training either.  Again, this is a conservative estimate; while you may plan to work 40 hours a week for your clients, you shouldn't make financial plans based on this number.

Finally, figure out your likely utilization.  Many consultants estimate 50%; that is, they don't expect to work more than half time, so they need to bill a high enough rate to cover the rest of the year with that. Life will be great if you can get close to 100% utilization, but unless you have a very full sales pipeline or some guaranteed long-term projects, you're living dangerously if you do any financial planning on that basis.

Once you've done all that take your expenses and divide by your potential billable hours multiplied by your utilization.  That's your break-even hourly rate, the rate your company can bill without losing money. If your company wants to make a profit, you need to bill something higher than this or get higher utilization (or both).

Note: This is a corrected version of the original post. Thanks to an anonymous poster (see comments) for pointing out my miswording.

I'm trying to drum up new clients for my my consulting firm. The market is tight right now and it's a lot of work.

I've tried a little bit of cold-calling. The theory is that it's a numbers game, that if you just play it enough you'll make sales. Unfortunately, given the services that my company offers (custom Mac OS X & Java development and outsourcing vendor evaluation), "enough" seems to be a pretty large number.

I haven't tried some of the more traditional marketing methods yet — brochures, targeted mailings, and so on. I'm not confident that I could reach the decision-makers that I need to using these techniques though. I know brochures and targeted mailings are a bad way to reach me as a decision-maker within my company.

I find referrals are the best source of new clients. I'm defining "referral" rather loosely; a client that I did some work for directly asked me to work on a project for them for one of their clients, and I'd call that a referral too. I find that if I can get an introduction from someone else to a decision-maker and talk with them about their near-term needs, I stand a pretty good chance of being able to do some work with them.

The down side is that the Macintosh community is kind of small, so even if you're reasonably well-known and well-thought-of within it it can be hard to get the contacts that lead to new business.

Right now, for example, I'm trying to find companies and organizations that are engaged in workgroup-scale or larger switches to Mac OS X so I can offer them software development and porting services. Most organizations above a certain size use at least one or two internal applications to improve their workflow. Since these are typically written for Windows they need to be ported, recreated or re-imagined on Mac OS X. Many switching organizations also aren't yet plugged in to the larger Macintosh community, so they may not know who the top-tier service providers are, they may not have a complete picture of their technology options, and may not know who in their area to turn to for advice. Which makes it all the more important to start getting them connected.

You'd think Apple would have directories or resources that Mac-oriented service providers could use to get in touch with these types of organizations. They likely have some intelligence on switching companies, but don't seem to be sharing it with those of us on the outside. (Even with members of their Apple Consultants Network program, evidently. My company's not a member so I don't know firsthand.)

Fortunately I've always tried hard to be a sponge and a radiator, soaking up all the information I can and then sharing everything I know as widely as possible. This winds up getting me a decent amount of whuffie, which I need to start seriously dipping into in order to get new business. Hopefully I can use my network to start wiring some switching organizations into the larger Macintosh community, even without all of it turning into new business.

In a New York Times article about offshore outsourcing, one of the participants in a roundtable asserts that programming is a "low-skill" job while project management is a "high-skill" job.

Uh, what?

It's true that good project managers are very highly skilled. But so are good developers! The fact that there are a whole lot of very bad developers out there doesn't mean there aren't also some very good ones who are worth what they demand. Just like the existence of a whole lot of very bad project managers out there doesn't mean that good ones aren't worth looking for.

Eric Sink, the founder of SourceGear, has this to say on programmers versus developers:

Instead of "programmers" (people that specialize in writing code), what you need are "developers" (people who will contribute in multiple ways to make the product successful).

My apologies if I'm trying to be too cute with my word definitions, but it really doesn't matter what terminology you use. In a small ISV you can't afford to have people who think their only responsibility is writing code. There are far too many other things to be done, all of which are critical to having a successful product. If you were a BigCo, you would just hire more specialists until every job function is covered. But as a small ISV, what you need are fewer people who are more versatile.

I think that he's on the right track but still a little off-base; while a BigCo would just hire more specialists until every job function is covered, almost all would be better off hiring more (but not quite as many) highly-skilled generalists. Unfortunately, highly-skilled generalists aren't fungible commodities so evaluating and hiring them is a bit more work than just résumé buzzword-matching.

Dispatches from the Frozen North, Spring?

We have another channel, call it A, which is a gigantic services company which has probably done work for every one of the Fortune 500 at one time or another. A is the prime contractor on a massive project, call it Project 123, and wants to bid us as part of this project. N is a subcontractor. Even though our involvement on these projects is usually a footnote to an asterisk, Project 123 could generate a substantial amount of business for us over the next year, plus get us deeper into A for future projects.

So, of course, when N hears that A wants to bid us for Project 123, N starts complaining. "Project 123 is our project! You need to go through us!"

"N, our job is to make sure we're part of Project 123 by hook or by crook, and until you give us a purchase order, we're going to pursue Project 123 through every means we have available. Never mind that your sales team working the account never even mentioned us, and that we've been developing a relationship with A for well over a year. Never mind that you haven't gotten your act together to be giving us the level of business you should be. Never mind that A is the prime contractor and you're just another sub like us. And never mind that this project is being handled by a completely different part of N. Just give us the P.O. Until then, it's put up or shut up."

That's not what I say, of course. What I say is, "We want to make sure this is a win-win situation for everyone, and we'll give you whatever sales support you need to help A make an appropriate decision about sourcing our services."

I wonder how things would've turned out if he'd actually said the first part. While I'm not absolutely opposed to doing so in the future, I have to say that I've found working through third parties and intermediaries doesn't add much value for either my own firm or the client firm.

There's a reason that the denizens of alt.computer.consultants.moderated call third-party brokers "borkers." There's a lot of utility in having a network to work through. But the "prime contractor" model doesn't provide it.

I think a "finder's fee" model provides much more value to the consulting firm and to the end client. In this model the firm that actually does the work (WorkerCo) is a client of the firm that finds the work (FinderCo). And the firm that benefits from the work (ClientCo) is a client of the firm doing the work. So ClientCo pays WorkerCo, and for some period after doing the initial matchmaking WorkerCo pays FinderCo a percentage of billable hours. Or WorkerCo pays FinderCo a flat fee. Or WorkerCo pays some percentage on a not-to-exceed amount. There are plenty of ways to work it all without FinderCo being the "prime contractor" and trying to funnel every single thing to do with the project through themselves.

Emery P. Dalesio (AP), "Business etiquette catching up to a wireless world" (newsobserver.com) [via Techdirt] Semiconductor maker Intel Corp. last year tested the value of an office wireless network on about 800 employees from engineering to sales. The employees found they had 23 minutes extra per day to accomplish their work, said Brian Tucker, an Intel marketing manager for mobile equipment who conducted the study.

23 extra minutes per 8-hour workday translates to a 4.8% productivity improvement. That may not sound like much, but it's effectively two weeks and a day per year of additional productivity. Assuming the average knowledge worker's fully-loaded cost is around US$50/hour (a reasonable back-of-the-envelope number) that tranlates to a US$4400/year annual return per worker.

That's just for deploying 802.11 networking to workers that very likely already have laptops and just need access to very inexpensive base stations on the company network via very inexpensive wireless cards. The Intel people in the article I excerpted are too pessimistic; this, like weblogging for knowledge management, is the sort of technology where you can start seeing ROI in a matter of weeks.

I've posted another article in the Articles section of my company's web site. This one's on the potential Return on Agile Development.

I'm going to try to write an average of one to two articles like this every week for my company web site. I'll also probaby mention them here, and if you want to keep up to date you can always use a feed-monitoring tool like NetNewsWire to subscribe to the RSS feed.

I'm doing this because I've found that the more good, hyperlinked, textual content there is on my company's site, the more hits I get from search engines. (Especially Google.) And with my site layout, I've found that people tend to browse around once they're there. Now I just need to figure out how to turn up the sales pressure a notch without being crass about it.

I was thinking today about which large software projects have had huge impacts on the way we create software. The ones I can think of off the top of my head are:

IBM OS/360

The project that gave rise to Fred Brooks' The Mythical Man-Month and the concept of software engineering.

Space Shuttle Onboard Software

The project which inspired the Carnegie Mellon University Software Engineering Institute Capability Maturity Model.

Chrysler C3 Payroll System

The project that led to eXtreme Programming and other agile methodologies.

Any other suggestions? I'd like to have an up-to-date list at some point.

Someone remind me to write something on treating sales as a form of engineering at some point.

(After all, anything can be engineering if you just squint hard enough!)

A couple days ago in Joel on Software, Joel claimed that in order for it to make economic sense to develop a Macintosh product, you had to be able to sell 25 times as many copies as you would a Windows product.

Bullshit.

First of all, you can't just assume that the relative market sizes between the Macintosh and Windows are accurately represented by their market shares. This is partly because market share is a measurement of new computer sales rather than installed base, and partly because there are broad swaths of each market that aren't in the market for your application.

Secondly, it presumes that it costs the same to develop and bring to market a Macintosh product as it does to develop a Windows product. It doesn't. It costs substantially less. The development tools on Mac OS X are the best on any platform, and speed development significantly; very small teams can create high-end applications in very short timeframes. There is a far smaller test matrix when you're dealing with Macintosh software, and within that matrix there are far fewer bizarre interactions. There is significantly less competition in the Macintosh market, so you don't have to spend as much on marketing and promotion of your product. Consumers also don't have to wade through nearly as much complete garbage to discover the good applications.

Finally, you have to consider post-sales support. The support load presented by Macintosh software is also far lower than for the typical Windows product. This means lower post-sales costs, which means you get to keep more of the revenue generated by the product.

All this adds up to an excellent ROI story for Mac OS X development. You may still have the potential for a higher return on a Windows product, but you'll also have substantially higher costs, a longer development timeline, and correspondingly greater project risk. All sides need to be weighed before deciding whether it's worth pursuing one platform or another - you can't just do a couple bogus back-of-the envelope calculations and decide you need to sell 25 times as many units to make Macintosh development worthwhile.

Last night I promised I'd describe the Point System from How to Become a Rainmaker. So here it is.

For every sales-related thing you do, you score some points. A new contact is one point, an appointment is two, a face-to-face sales call is three, and a sale is four. The goal is to get four points every day in some combination.

Since I've had relatively little exposure to the sales process, I've been reading up on it. As I said yesterday, How to Become a Rainmaker was fairly good but puffy. (I'm finding this is the case with a lot of business books.) I found Selling the Invisible by Harry Beckwith a much better book on the theory of selling services. But lately I've been a little more in the mood for practical, how-to advice.

shoebox_bird asked which books I was lent. Rob lent me Shadow & Claw and Strange Travelers by Gene Wolfe. I had dinner with Gene and a bunch of other people at Capricon, but I hadn't read anything he's written yet. Rob offered to rectify this...

I haven't started reading the books, but I'm sure I'll get to them soon. I've finished a couple of the books I was reading and I'm almost finished with the other two. And I'll need something fun (rather than business-oriented) to decompress with over the next few weeks as I finish another project for a client.

So what have I been reading? Cocoa Programming for Mac OS X by Aaron Hillegas, which I very strongly recommend for anyone thinking about taking the leap into Objective-C and Cocoa. I took Apple's Programming WebObjects I course when Aaron taught it in June 2000, and he's a really great teacher. I also just finished How to Become a Rainmaker by Jeffrey J. Fox. It's a short, puffy book, but it had some good ideas on sales. I'll describe one of them, the point system, in a little more detail soon.

In my pipeline (yes, I am a consultant) I have Professional WebObjects 5.0 with Java, which is a great read for anyone doing WebObjects development by a lot of heavy hitters in the field. I'm almost done with it, just finishing the NetStruxr case study. Then there's The Secrets of Consulting by Gerald M. Weinberg, which is kind of trite and silly but also contains lots of good nuggets of advice on dealing with clients, why people hire consultants, and so on. I'm about 2/3 of the way through it. I'm also about halfway through The Art of Seduction by Robert Greene.

Then there's the stuff I'm queueing up for a rainy day. The collection here includes Ways of Seeing by John Berger, Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihaliyi, Kerberos: A Network Authentication System by Brian Tung, The Clock of the Long Now by Stewart Brand, The Dream Machine by M. Mitchell Waldrop, and it's not the BIG that eat the SMALL ... it's the FAST that eat the SLOW by Jason Jennings & Laurence Haughton.

(Don't worry, Rob, I'll get to your books before those... Most of the above isn't the kind of decompression book I'll need.)

Oh, I also have a ton of magazines piled up to read. I'm slowly working my way through a pile of old issues of Harvard Business Review, Strategy+Business, and Fast Company. There are a couple MacTechs thrown in there for good measure. I just finished the January 2002 issue of HBR today, which had some good stuff I'll post about later.