Tim Anderson's ITWriting

May 13, 2005

How long should a tech book be?

Chris Sells asks what's the right length for his new book. The book is on Windows Forms programming in .NET 2.0, and it's the kind of thing I might well read since the subject interests me. Chris explains that it's turning out at 1200 pages or more, but the publisher wants no more than 800 pages as longer books don't sell so well.

My advice: cut it. The best technical books are shorter. I spend half my writing time cutting stuff out; it hurts, but the end result is usually a better piece of work.

There are exceptions. Two cadidates among .NET titles I have on my shelves are Adam Nathan's .NET and COM (1608pp) and Francesco Balena's Programming Visual Basic .NET (1440pp). Tne thing about Nathan's title is that it covers a complex topic that is severely under-documented in the official .NET online reference. I doubt it lost any sales by being long. Casual developers won't pick up the book, and those who need it buy it as soon as they see it. On the other hand, if the official documentation were up to scratch, Nathan's book could be much shorter.

Balena's title is too long, good though it is. The thing is, we don't need to be told things we can easily find online, such as a reference to the Regular Expression language. What we want from experts is their expertise, the non-obvious things, the things that make the difference between an application that runs and an application that delights its users.

So if Sells is writing a reference, Microsoft should put in in MSDN and ship it as online documentation with Visual Studio 2005. If he's writing a programming book, he should cut the pages that everyone will skip past anyway.

Here's a great tech book. Refactoring, by Martin Fowler. Page count? 464pp.