News

The first thing we do, let's kill all the authors

• By Mike Gunderloy
• February 16, 2004

One reason I keep reading weblogs is that they toss up thoughtful discussions of development topics from time to time, along with sample code, the weather, cute kid stories, and pretty much everything else under the sun. Case in point: Sam Gentile's recent weblog entry "Why don't .NET developers grok scalable distributed computing?" In this entry, Sam discusses the fact that when he looks at .NET books, blogs, conferences, and so on, most of what he sees are the exact same type of client-server two-tier application that we were building in the 1980s, with no middle-tier business rules or good scalability. This is despite the availability of good technologies (MTS, COM+, Enterprise Services, Remoting, Web services, and the coming Indigo) to help .NET developers come up with truly scalable architectures. Given this mismatch, it's fair to ask what happened.

Sam points at part of the problem with his observation "I had the chance to go over just about every ASP.NET book out there and their 'data chapters'; over twenty of them at last count Not a single one of them ever talked about distributed data access except for one - Homer and Sussman's Distributed Data Applications with ASP.NET. In fact, many carried on about choosing DataReaders almost exclusively and even passing them around in layers. This is not to mention all the other problems with the books being highly simplistic and non-real world." There's a big problem in the computer book publishing world that we mostly ignore: business pressures tend to push even caring authors towards mediocre books.

Take my own ADO AND ADO.NET PROGRAMMING, for example (you might as well take it; very few people actually bought a copy). Weighing in at an even thousand pages plus a CD, and covering both "classic" ADO and the newer ADO.NET, it doesn't mention distributed data access at all. Remoting, COM+, Enterprise services: all absent. I did manage to get in a few pages on Web services, which are almost embarassingly simplistic. Perhaps it's just as well that you didn't buy a copy.

So how does this happen? There are pressures both monetary and schedule-wise on the author. Unless you're living in a garret (and probably not even then), book advances are not large enough to keep an author alive, so the temptation is always to take the advance and write as quickly as possible while doing other work on the side. Much as we might like to write good real-world, well-researched books, there's no way to make that work financially in most cases.

And even if there was a way to make it financially, the publishers wouldn't let us take the time. There's always more pressure to meet impossible deadlines, to have the book ready the day the product hits the shelves, to revise for the next version before it's ready to ship. The result is rushed books with factual errors, because authors mostly don't have the ability to check against final shipping code. With these hurdles to clear, it's a wonder that we can get a halfway accurate book published at all, let alone one that contains deep thoughts on cutting-edge topics.

There are exceptions, of course. Every once in a while, some author turns out a labor of love, perhaps supported by an enlightened employer. But these books are scarce.

So what's the answer? Certainly there are a lot of applications out there that will benefit from really scalable designs, and just as certainly you won't find those designs in most .NET books. But books are not your only resources. One place to fish around for more information is the Microsoft Patterns & Practices Web site, which contains an increasing amount of information straight from Redmond about building applications -- and certainly, with tens of thousands of employees distributed worldwide, the company has some reasonable experience on distributed applications. You can also keep an eye out for those rare books; Martin Fowler's PATTERNS OF ENTERPRISE APPLICATION ARCHITECTURE, for example (while not .NET-specific) will help you think about the issues involved. But in the long run, there's probably no substitute for spending time in the trenches with your chosen technology, and trying to actually employ best practices as you build applications.