Build a tool and then extract a library

Recently, I wrote tool X that accepts a Boolean SAT formula (in conjunctive form) along with a model/interpretation — an assignment of truth values to variables in the formula — and checks if the model satisfies the formula.

Then, I started planning for a tool Y that identifies a satisfying model (if one exists) for a given Boolean SAT formula. Clearly, tool Y could use the algorithm in tool X as a subroutine to check if a model satisfies the formula. For reasons such as efficiency (avoid data transfers between programs via the file system), simplicity of use (install one tool), and avoiding code duplication, it is better if tool X could be refactored into a tool t-X and a library l-X where t-X uses l-X. This would enable tool Y to use library l-X and be more efficient, simple, and avoid code duplication.

While all of the above makes sense from a software engineering perspective — reuse, simplicity, reduced code duplication, etc., I am now wondering “should I refactor tool X into t-X and l-X before I implement tool Y?”

Is one possible reuse good enough to refactor out a library from a tool?

I think the answer is No. My reasons are as follows:

  1. One possible reuse is not the same as one reuse. For all I know, it may be a sub-optimal idea to use the algorithm in tool X as subroutine in tool Y. So, it is better to verify such use is indeed optimal and then refactor tool X and tool Y.

The above is nothing more than avoiding premature optimization.

Now, off to implementing tool Y :)

Written by

Programming, experimenting, writing | Past: SWE, Researcher, Professor | Present: SWE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store