Learners love a time limit and experts hate them. Time limits are popular in tutorial books, and in technical publishing SAMS has built their brand on time limited tutorials:

• SQL in 10 minutes
• PHP in 21 days
• MySQL in 24 hours

Experts tend to look down on these books. Not just if the content is bad (usually it’s OK) but the concept too. “You can’t learn programming in 24 hours — it takes decades”, they snort. “I still don’t know all of SQL and I’ve worked with it for 5 years” they bleat.

But time limits work great in tutorials, especially for introductory topics — topics where the reader has a general idea of their goal, but very little idea of the steps required to reach it. Here’s why:

• It offers a constraint that anybody can understand. Everybody understands the passage of time, so they see a book that promises to introduce the topic in a fixed time and they can assess whether the investment is worthwhile. Especially if the book describes the outcome in a credible way that isn’t full of jargon. (Hint: describe what the reader will acheive, not what they will do — because they likely won’t understand what the steps / actions involved mean.)
• There’s a built in narrative. Technical books are often boring, and skilled authors try to give readers a reason to keep turning the pages besides the information itself. Working against the clock raises the stakes, makes it more exciting, tells a story. “With only 8 hours left, can we learn the crucial features of PHP necessary to reach our goal?” Just about any action TV series or movie has a ticking clock during the last half. It’s a clunky device — but a reliable one.
  
• It promises efficiency. Specify a strict deadline, and you are promising that you will cut corners and needless detail. It’s implicit in the time limit that it’s less time than you really need — so we’ll skip stuff. Readers like to think that the author is cutting the boring bits and giving them the absolute need to know stuff. Every minute counts — so we’re not going to spend the first 60 of them on ‘the history of MySQL’.
• It focuses on the reader and on ACTION. PHP in 250 pages isn’t so compelling. Up against “PHP in 500 pages” at the it might even sound a rip off. But using time focuses not on the content in the book, but on what the reader will do when they get it. It’s impossible when you see these titles not to imagine yourself behind the keyboard, book to your side, hacking away. It brings the book to life.
• It promises a miracle. People love miraculous quick fixes. They love the idea that they are buying something that’s impossible. Working to an unrealistic time limit does that. Experts snort at this in the way that scientists snort at tribal religions — they are educated past it, but when you’re bewildered a witch doctor is much more compelling than a science degree.

You might not want to build your book title around a time limit, but it’s worth thinking about those factors above with any book project. Can you get those qualities into your book without compromising on your title?