API, Design, Technology

Reusable components: design or extract?

Are you always DRY or perhaps you follow the Rule of Three?

I’m currently working at a software company that has two business models, one is the familiar contracted services dev shop, the other is publishing a public set of API’s to accelerate application development.

We always try and look for opportunities to extract a reusable component out of project work, and include it in the API product.  However there are times we also are asked to design an API first, add it to the API product, then incorporate it into a running project.

Designing API’s for public use is difficult, designing an API for public use without pulling for an existing implementation, example or proof of concept is even harder.  

It has been my personal experience that I often need to refine an idea a few times before I feel its ready for public release.  To me, trying to build an abstraction over a concept in the form of an API, requires a level of knowledge and thus becomes an effort to generalize, versus lack of knowledge and an effort of mostly speculation.  I try to avoid premature generalization

When building an API, I generally prefer the extraction of proven functionality from a previous effort/project.  In the past this also was my preferred way of identifying code to pull into private library.  Over the years I’ve become more comfortable with the idea that I’ll make it easier to pull things apart but not worry all the time about creating more and more abstractions in my code.  

However, I do think we need to be careful and see if the “rule of three” can apply as we develop code.  If I find myself writing the same code or copy/paste-ing the same code I’ll extract it to a common method or API implementation right then.

What about you? 

When do you prefer to create an abstraction?
Comment on Reddit