DEV Community

Binoy Vijayan
Binoy Vijayan

Posted on • Updated on

Mastering Quick Estimates: Unveiling the Power of Back-of-the-Envelope Calculations

In general, a back-of-the-envelope calculation is a rough, informal estimation or calculation done using basic math(arithmetic) and primary assumptions. Since this can be done informally, perhaps on a scrap of paper or the back of an envelope, it is referred to as a back-of-the-envelope calculation.

Below, you'll find the typical steps for performing a back-of-the-envelope calculation.

Identify the Problem: Clearly define what you're trying to estimate or calculate.

Gather Basic Information: Collect any relevant numbers or data you have regarding the problem. This might include approximate values or rough estimates.

Make Assumptions: Since you're doing a quick calculation, you'll likely need to simplify the problem by making some assumptions. These assumptions should be reasonable and should help simplify the math.

Perform Simple Calculations: Use basic arithmetic or other simple mathematical operations to arrive at an estimate. Round numbers liberally to make calculations easier.

Check the Results: After you've done your calculations, it's a good idea to check if the result makes sense given your assumptions and the problem at hand. If the result seems significantly inaccurate, you might need to revisit your assumptions or calculations.

Example

Problem

Estimate the number of buildings in a town

Information:

You know the town covers an area of about 1000 square kilometres and the buildings are distributed relatively evenly throughout.

Assumptions:

Assume an average building density of 5 building per square kilometre (this is a rough estimate).

Assume buildings are evenly distributed throughout the town.

Calculation:

Total number of buildings = Average building density * Area of the town

Total number of buildings ≈ 5000 buildings/square kilometre * 1000 square kilometre = 5,000 buildings

Check the Results:

Does 50,00 buildings seem reasonable for the size of the town and the assumed building density? It's important to consider whether the density you've assumed matches the actual conditions of the town, and if the result aligns with your expectations.

In the context of Software System

In software system design, a back-of-the-envelope calculation can be used for various purposes, such as estimating system requirements, sizing hardware resources, or understanding performance characteristics.
Let's consider an example of estimating the storage requirements for a database system:

Problem

Consider the database should store the records for a small online retail business.

Each record contains basic information about a product, such as name, description, price, and inventory level.

Product    =    {
                name: String
                description: String 
                price: Double
                inventoryLevel : Int
            }

Enter fullscreen mode Exit fullscreen mode

The business plans to start with 10,000 products and expects to grow to 100,000 products within a year.

Assumptions

Assume each record will require approximately 1 kilobyte (KB) of storage space(Not considering actual data-types and approximate required size for the each information). This includes the overhead for indexing and metadata.

Assume there will be additional overhead for indexes, transaction logs, and other database management operations, which will double the storage requirement.

Calculation

Total storage requirement for 10,000 products:
= 10,000 products * 1 KB/product = 10,000 KB
= 10,000 KB = 10 MB (since 1 MB = 1024 KB)
Total storage requirement for 100,000 products (including overhead):
= 100,000 products * 1 KB/product * 2 = 200,000 KB
= 200,000 KB = 200 MB

Check the Results

Do 10 MB for 10,000 products and 200 MB for 100,000 products seem reasonable given the assumptions? It's important to consider factors such as future growth, data retention policies, and any additional overhead for backups or redundancy.

Why this is important ?

Quick Estimation: They provide a quick and rough estimate of various aspects of the system, such as storage requirements, processing power, or network bandwidth. This allows designers to get a rough idea of the scale and resources needed without investing significant time or effort in detailed analysis.

Initial Planning: Back-of-the-envelope calculations are useful during the initial planning stages of a project when detailed requirements may not be available. They help stakeholders understand the approximate scale of the system and make high-level decisions about architecture, technology choices, and resource allocation.

Feasibility Analysis: They help assess the feasibility of a project by estimating whether the proposed solution is technically achievable within the available resources and constraints. This can prevent investing time and resources in a project that may not be viable from a technical perspective.

Risk Mitigation: By identifying potential bottlenecks, limitations, or challenges early in the design process, back-of-the-envelope calculations allow designers to proactively address these issues and mitigate risks before they become major problems during implementation or operation.

Communication Tool: Back-of-the-envelope calculations serve as a communication tool between technical and non-technical stakeholders. They provide a simple way to convey the scale, complexity, and resource requirements of a software system in terms that are easily understandable to a wider audience.

Baseline for Detailed Analysis: While back-of-the-envelope calculations are rough estimates, they provide a baseline for more detailed analysis and refinement as the project progresses. As more information becomes available and the design evolves, these initial estimates can be revised and refined to provide more accurate predictions.

Summary

Overall, back-of-the-envelope calculations play a crucial role in the early stages of software system design by providing quick estimates, aiding decision-making, identifying potential risks, and facilitating communication among stakeholders.

Top comments (0)