devxlogo

The Code Reuse Paradox

The Code Reuse Paradox

Reusability has been one of the holy grails of programming since the dawn of digital computing. Instead of writing some code that does exactly what today’s requirements specify and no more, write some general purpose code that can meet today’s requirements as well as other requirements down the road. That way we can simply check that code into a library for people to use forever without ever having to tweak it.

Any developer who’s been down this road knows that achieving reusable code that actually meets the requirements for reuse is far more difficult than it sounds. First, developers must guess which functionality they should generalize. They must also understand how far to go to generalize it. And finally, they need to know when they’re done.

Let’s take a simple example. Let’s say our customer wants an application that can plot straight lines on a graph with two axes that range from 0 to 10. Take two (x,y) number pairs as input and draw the line. Sounds like an exercise from your very first programming class, right? Any programmer worth his or her salt could crank that out in less than an hour.

OK, now make the code reusable. Instead of limiting the two axes to 0 through 10, ask the user for the values of these limits. Now your graph can plot lines to any scale.

Done yet? Nope. Why stop at lines? What about other kinds of curves? Suddenly inputs of two number pairs won’t do. Instead, craft a way for the user to enter multiple number pairs. But that’s not good enough for many curves either. OK, let the user specify any kind of formula.

Great! Now we can plot any kind of curve we want. Oops, except we’re still stuck in two dimensions. Let’s let the user specify formulas using z as well as x and y. Now we have three dimensions … but remember the old programming adage that your code shouldn’t have any numbers in it except 0 and 1. Why stop at three dimensions? Might as well let the user specify as many dimensions as they want.

Are we done yet? Not if the user might want to put their graph into motion. If they specify a time variable then we have to build a whole animated graphing engine.

But why stop there?

Sure, the user can turn off all our added bells and whistles if all they want is a straight line. But we wanted to make our code reusable, so we spent months and thousands of dollars to make sure our code served far more use cases than we needed, and we don’t even know if we’re done with it.

There’s got to be a better way. I know! Let’s build a reusable Service.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist