By using rough order-of-magnitude estimates, you can check calculations and estimate whether tasks are even plausible before spending time to plan them more accurately.
An order-of-magnitude estimate is an estimate to the nearest power of 10. For instance, an order-of-magnitude estimate of 400 means the true value is closer to 400 than 40 or 4,000. The estimates we're discussing in this hack are called rough order-of-magnitude (ROM) estimates because we're not completely sure we're within an order of magnitude.
Other terms for this kind of estimate are ballpark estimates (as in, "Are we even in the ballpark?") and educated or scientific wild-ass guesses. As all of these names suggest, the idea is to determine roughly how large a number is, or whether a task is trivial, possible, or absurd.
Warning
When you're estimating tasks, make sure everyone understands that ROM estimates are just that. They should not be written into contracts or used as targets when actually doing work. That needs more careful estimation and project tracking. ROM estimates are just to know whether to bother performing a more formal estimate.
First, let's do a purely numeric hack: estimate how many seconds are in a year.
There are 60 seconds in a minute and 60 minutes in an hour; multiplying them is easy: 3,600 seconds in an hour. Let's round that to 4,000. Twenty-five percent might seem like a big round-up, but we are concerned here with orders of magnitude; as long as it's not 2,500%, we should be OK.
Now, there are 24 hours in a day. We rounded the seconds in an hour up, so let's round this down to 20. Multiplying 20 by 4,000, we get 80,000 seconds in a day, which we can round up to 100,000.
There are 365 days in a year (plus a bit). Let's round that to 400. Our final estimate (400 days times 100,000 seconds) is 40,000,000 seconds in a year, and since we rounded up three times and down once, it's probably high rather than low.
Tip
The actual answer, using 365.2422 days per year, is 31,556,926 seconds per year, so we are well within an order of magnitude (and we were indeed high, not low).
Now, let's do a similar problem estimating a task. In an episode of The Simpsons I just saw in syndication, Bart is in France as an exchange student for three months, but he ends up picking grapes at a run-down chateau. Supposedly, he picks a million grapes in that time (this is an estimate by one of the Frenchmen exploiting Bart).
First, let's see if 1,000,000 grapes seems plausible. Each bunch of grapes has some grapes on it—more than 10, certainly. Let's say 100. Each vine will have several bunches; let's say 10. So, we've got 1,000 grapes per vine, which means 1,000,000 grapes require 1,000 vines. If anything, that seems low for the vineyard pictured, so no problems here.
Could Bart even theoretically pick all those grapes in less than three months? Let's say Bart picks one grape per second, which seems plausible (he certainly doesn't manage 10 in a second, but he can do more than one every 10 seconds). At this pace, he'd manage 3,600 in an hour. Let's round that down to allow time to move between bushes, empty the container, and so on, but to compensate, we'll have him work 20 hours a day. So, Bart manages 60,000 (20 × 3,000) grapes a day. If we round that to 50,000 to get a nice factor of 10 [Hack #36], we see it will take 20 days (1,000,000 / 50,000, which is the same as 1,000 / 50) to harvest 1,000,000 grapes.
This is somewhat less than three months (which is about 3 × 30 = 90 days). So, an estimate of three months seems somewhat reasonable even though it was intended as humorous exaggeration—but there were a lot of guesses in there. If this were important, it would be worth doing a more careful analysis of things, such as Bart's grape-picking speed
The basic idea is to estimate anything you don't know and round off numbers to make the arithmetic easy. As you estimate and round, if you keep track of whether you're estimating high (rounding up) or estimating low (rounding down), you get a feeling as to whether your estimate is more likely to be high or low.
Rounding up one time and down the next will tend to cancel out (though of course this depends on how much you're rounding). That's just because using a bigger number in one place will cancel out using a smaller number in another. For instance, when computing the seconds in a day, we rounded 3,600 up to 4,000 and 24 down to 20, and multiplied them to get 80,000. The actual answer is 86,400 (3,600 × 24), and we're quite close. Notice that if we'd rounded both numbers up—say, to 4,000 × 30—we'd get 120,000, which of course is higher, but also further away from 86,400 than 80,000 is. Likewise, rounding both down—say, to 3,000 × 20—gives us 60,000; again, further away than 80,000.
Sometimes, you want to mostly round up (if it's work you're going to have to do) or mostly round down (if you're estimating feasibility). You might want to do both and use the two numbers as upper and lower bounds. For instance, in the example of the number of seconds in a year, we'd know that the number of seconds in a day is between 60,000 and 120,000.
ROM estimates can help you find mistakes in everyday life. They can help you in your job, and they might even help you get a job if you don't have one.
Mistakes on calculators can easily give answers that are wildly wrong. For instance, suppose we were computing the number of seconds in a year, and we typed this:
60 * 60 + 24 * 365
to get this:
12360
Since our earlier estimate when we tried to calculate the number of seconds in a year was 40,000,000, we know something went wrong.
At my work, we often use ROM estimates to figure out how long a customer request will take. We estimate tasks by week and add them up to get the total time. We can then compare that to the customer's schedule and budget.
Suppose, for instance, that someone asks Ron to write another book of mind performance hacks, but they want it in two months. Can he do it?
The book will comprise about 10 chapters with about 10 hacks in each chapter, for a total of 100 hacks (which might be an overestimate, but it's a nice, round number to shoot for). Some hacks are easier than others are, but we might say that, on average, each takes two hours to research, two hours to write a first draft, an hour for polishing, and an hour for technical review. That's six hours for each hack, for a total of 600 hours. At 40 hours per week, we already have 15 weeks, well more than two months. So, we can already tell that Ron will need some help, and we haven't counted the time to decide which hacks to use.
The task of deciding which hacks to write should also be figured in and is the kind of thing we tend to like to be generous in estimating, because it's hard to quantify. It's much harder to say, as we did with the writing, that it will take a definite amount of time per hack to think them up, and that time will probably have to be spread out more. On the other hand, we have some hacks in this book that might help.
Many software companies like to ask mind-expanding questions to prospective hires to test their ability to think big and creatively. One famous example is, "How would you move Mount Fuji?" Let's estimate the number of truckloads of dirt that would generate.
First, how tall is Fujisan? If you know, you can round that off, but I don't. It's a very tall mountain, so it's probably around 10,000 feet. Again, 1,000 is definitely too small and 100,000 is too big. But 20,000 would be equally plausible for this kind of estimate, or even 30,000, though that would make Mount Fuji taller than Mount Everest. If you'd rather work in the metric system, 5,000 meters or 10,000 meters would be a good estimate, which of course doesn't match the estimates in feet.
Tip
According to Wikipedia, Mount Fuji is 3,776 meters (12,388 feet) tall. So our 10,000-foot estimate isn't too bad.
Anyway, let's stick with 10,000 feet for now. Mount Fuji appears to be roughly a cone, with the base diameter about twice the height. (If you look at a picture of the mountain, you'll see the base is actually quite broad.) So, if we knew the formula for the volume of a cone, we'd be all set.
First, let's suppose we don't; all we remember is the volume of a cube, which is the side cubed. If we visualize a cube as high as the mountain, it looks roughly the same. For a ROM estimate, that's probably good enough, and the cube's volume would be 1,000,000,000,000 cubic feet (10,0003 = 1012).
If you do remember a bit more geometry, you'll recall that the volume of a cone is (area of base) × height / 3, and the area of the base is π × r2. Since we estimated the diameter of the base as twice the height, the radius (r) of the base is the same as the height. Putting this all together, we get π × height2 × height / 3. And, since π is about 3, we end up with 1,000,000,000,000 cubic feet (10,0003 = 1012) again.
OK, how much can a truck haul away? Probably a volume of 10 × 10 × 10 is not unreasonable (trucks aren't 10 feet wide, but they could be longer and that should make up for the width). So, one truckload is 1,000 cubic feet.
We would need 1,000,000,000,000 / 1,000 = 1,000,000,000 (one U.S. billion) truckloads, which is a lot. In this case, of course, there are many other problems with moving Fujisan; for instance, the Japanese people would probably object!
Mark Purtill
Get Mind Performance Hacks now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
