I’d been putting off building an abstracted search query library for a while because I knew it was a big concept with a lot of options and was going to be hard to get it organized right. When I finally built it, I ended up taking an approach I hadn’t used before, and I’m really amazed at how well it worked.

Instead of stubbing out the library code and working on it from the building blocks up, I took a different approach. I first wrote the code in the controller that would execute the search. I included calls to methods in the model that didn’t exist yet, but coded the controller how I thought it should work in the most elegant fashion.

Then I created the model to implement the methods used in the controller, and in doing so I created code that made calls to my search library – including handling return values, etc. – again, coding the model in the way I thought would be optimal. I ignored the fact that the library hadn’t been built yet.

In doing this, I didn’t define abstract interfaces for the library, I defined specific interfaces. I did it not by trying to analyze the entire big problem at once, but by skirting it and focusing instead on the code that would interact with it. Code that was much simpler to tackle.

I had a fully coded controller and model that was using my not-yet-written library which provided a very clear pattern for the methods and properties needed in the library. By figuring out how I was going to use the library, specifically, not abstractly, it did the work of defining the library structure for me.

Once the library requirements (including some of the interfaces) were clearly laid out, the task of writing the library changed. It went from a big conceptual solution that had so many options as to be paralyzing, to a very straightforward implementation exercise.

I believe I can take this and extrapolate it to larger abstract development projects, like building APIs. I’m excited to see if it continues to work as well as it did in this situation.