EntBlog
Code, 3D, Games, Linux and much more...

Back-of-the-envelope

There is a technique not widely known in computing engineering that is very useful to estimate calculations: back-of the-envelope calculations. Being able to estimate properly is crucial for software engineers. Of course, there is a lot you can learn by the experience. But this skill can be improved with training.

Back-of-the-envelope calculations estimate based on rough approximations than can be derived from common sense. The back-of-the-envelope term comes from the idea that those calculations are so simple that you can write them down in the back of an envelope. Obviously you don’t have to use an envelope at all for this technique.

You need a question whose answer doesn’t have a practical way to be exactly calculated. For example, how long would it take you to fill a floppy disk by typing? A floppy disk contains 1.44 megabytes. Estimating that you can type at a rate of 50 words per minute (300 bytes), you write 1 kb in 3 minutes, 1Mb in 3000 minutes and 1.44 in 4500 minutes or 75 hours.

As you can see, you round your calculations to easy numbers in the same order of magnitude. Extrapolating knowledge is useful too. If you like to read more about this, I recommend the book Programming Pearls by Jon Bentley. It is online, and the chapter about this can be found here.

Apart from obvious rules, there are more interesting ones. For example, Jon Bentley describes the Little’s Law in his book: “The average number of things in the system is the product of the average rate at which things leave the system and the average time each one spend in the system”.

An example using the Little’s Law to estimate your city’s death rate, measured in percent of population per year: if the life expectancy is 70 years (1 person = 70 (average rate) * death rate) then death rate is 1/70 or 1.4% of the population each year.

And now, more interesting questions (without answers…): How much time does your team spend waiting for the compiler to finish its work? How much money does your studio lose due to that? How much time will take that new feature? When will the game be ready for production?

Want to evaluate your proficiency estimating things? Try this quiz. I got only a poor 5. Probably, I need to improve my estimation skill. What did you get?