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.
About the Author
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.