# Over-Engineering a Code

Say you are a software engineer, or developer, or whatever other abstracted
word for *programmer* that has some meaning to you. Say you have also been given
some scientific computation problem, like estimating the value of with the
Monte Carlo method.

Inscribe a circle of radius in a square of length . Then the probability a random point generated in the square is also inside the circle is equal to the ratio of the circle’s area to the square’s, which is .

We now have a method for approximating by generating a set of random points in the square and finding the ratio of those points also inside the circle. This value multiplied by 4 gives us an estimate of , which becomes more precise with an increasing volume of generated points.

Your friend is an electrical engineer, and knows how to program in JavaScript. She quickly codes a simple, easily-understandable procedure:

Youperhaps vicariously through another, having already taken on some abstracted title for yourself, chose instead to over-engineer her perfectly good solution to be *TheBestCode*™

## #1: Everything Functional

Since the only operations done here are on an array, all the loops can be eliminated in favor of immutable function calls on the original array. Even the instantiation of random points in the array can be sugared into the initializer.

##
#2: On `inCircle`

~Idiomatic~read: new age JavaScript calls for arrow notation on small functions, so that’s what we’ll do. We can also allow for a variable circle radius - of course, that’s totally useless for this example, but makes the function more ~scalable~. Finally, there is a marginal cost reduction in comparing the square of the euclidean distance to the square of the radius rather than computing a square root.

This gives an artisanally-crafted code:

We’re not done yet. If we take a quarter circle of radius 1 inscribed in the square instead, the ratio of quarter-circle-to-square area remains , but now the center of the circle is at the origin, which eliminates two subtractions in the function call. The code is made even more idiomatic with JavaScript’s exponentiation operator.

For now, this will be our final form:

## #3: Defining and Objectifying

But what *is* a point? In this case, a pair of coordinates. Let’s define the points as named tuples:

We abstracted `inCircle`

to be of any radius earlier, but of course that’s kind of useless since the function is specifically designed for measuring . What we should do is wrap our estimation script into one experimentation procedure that accepts a variable point sample size. This is the **ultimate abstraction** we could ask for.

After a multitude of revisions and totally misaligned priorities, we arrive to modular paradise.

## #4: Why?

I’m not sure. I would love to give a practical reason to over-engineering small codes besides as an exercise in program design, but I’m not sure there is one. If you think of one, please let me know. Otherwise, perhaps the only lesson here is that I have some kind of compulsion for modularizing codes to my liking.