When Frameworks Happen

I discovered CouchDB in the middle of writing Gregor, the new documentation engine that runs the recently launched CodeStrong site. It was a novel technology for me, and I just knew I had to use it for Gregor. So, after getting permission from the higher-ups, I decided to rewrite Gregor, ditching MySQL and the additional ORM layer, and port everything to use CouchDB.

But instead of just diving into the action and writing the code for Gregor itself, I did something stupid: I wrote my own REST client for CouchDB. It’s not that there wasn’t any PHP clients available, it was just that I didn’t like any of them.

I spent around 3 days writing the whole thing, which I named “Chill,” and it was great. But to make the long story short, Gregor never saw Chill. After completing a large part of the framework, I opened my Gregor project files, took out the core CURL and Request classes from Chill and never looked back. It turns out, I didn’t actually need any of the functionality I wrote.

That’s when I realized that frameworks aren’t made. They happen.

The Joy of Frameworks

The root of the problem is that creating frameworks is enjoyable. In fact, they become so enjoyable that, often, we create frameworks just for the sake of creating them. We don’t actually use the framework, we just imagine how it might be used.

But creating a framework out of thin air is mostly guesswork. You have no concrete parameters for decisions about what to include or what to leave out and worse, you’ll probably end up with a bunch of things that seemed like good ideas, but end up useless in actual practice. It’s like buying furniture for a house that hasn’t been built or even drawn yet–you’re given endless possibilities, but until you actually know the measurements or the layout of the building, you’re just playing Ikea Russian Roulette.

One could say that that’s what the YAGNI principle is for. But here’s the thing: the YAGNI principle fails when you have no parameters to base your decisions upon. How will you know what to leave out when you don’t even know what you’ll really need in the first place? Programming isn’t about being psychic–we’re trying to solve real problems, not nonexistent ones.

Don’t Create Frameworks

Let’s cut to the chase: don’t create frameworks. Instead, discover them.

With Gregor, I used an awesome microframework called Nice Dog from Tiago Bastos. It was a pretty simple framework, just consisting of functions to handle the barest essentials of routing, controller handling and view rendering. It worked well for me, and when I found that I needed stuff that weren’t included within the framework itself, I just added them in. I had so much fun using Nice Dog that when I decided to write a simple blogging engine for Keetology, it was my only choice.

During the course of writing the new blogging engine, I realized that I needed some functions I wrote from Gregor. Patterns began to emerge and I ended up with my very own version of Nice Dog. It was never my intention to create my own framework based on Nice Dog–it just happened.

And it’s not a rare case. The truth is most frameworks start that way: people start seeing things being done repeatedly across their applications, patterns start to emerge and they realize that instead of writing the same thing all over again, they could just create a framework to handle the repetitive code.

The value of this approach to framework building is that all your decisions will be grounded on actual practice. Your apps will show you what is really needed, and what isn’t. You’ll end up with a leaner, more focused framework that you know works for actual application. And those are the frameworks that really matter.

So the next time you want to create a framework, build apps instead, then rectify, simply and discover. Frameworks happen, and that’s how it all should be.