⇥ I ATE YOUR FRAMEWORK

After yesterday’s “pH reduced” post on Rails and bloat, I received no less than ten e-mails from people asking me how my thoughts apply to this framework or that (seriously, people, my blog does have a comment system; use it!).

My answer is always the same: I don’t know. You’re the consultant—you figure it out. I’m just the guy who gets to pick up the phone and yell at you when things don’t work.

Since any conversation on frameworks inevitably ends up in someone asking what it is that we do that makes us so special, let me skip ahead to the forgone conclusion and tell you how we code our applications at php|architect. I claim no particular genius behind our code—it’s just how we do things.

When Sean and I put on our architect hats and sat down to redesign the entire php|architect stack (which was so close to end-of-line that it was about to flatline), we set up a few ground rules for the overall framework:

• Write as little software as you can get away with. Code with human readability in mind, and don’t even think the word “optimization.” As a rule, we solve every problem ad-hoc unless there is pre-existing code that can be easily adapted to it, in which case we refactor.
  
  
• Don’t invent. With one exception that has a very good reason behind it, our entire system is based on the best possible pre-existing technology for a given job: PHP for the backend, MySQL for our database systems, XSL for our frontend. Whenever someone says the words “custom templating system,” an angel loses his wings, and a fluffy bunny dies.
  
  
• If you can’t understand it, you didn’t do it right. One of the most controversial decisions that I insisted on was that under no circumstance there should be more than three levels of inheritance anywhere in our code. Three is, of course, an arbitrary number, but it has helped keep the complexity of our code down. If you need more than that, it’s probably time to branch your code into simpler chunks anyway.
  
  
• Write for humans. Since so much of our strategy depends on refactoring, the code we write needs to be written with that particular technique in mind. We agreed to write code first to make sure that we could read it, and then worry about optimization later—as it turns out, we never had to worry about that.
  
  
• Write secure. Our code is just plain paranoid. All input and output goes through a single filtering class that has priority over anything else. If it sniffs something out of place, it pushes the big red button and throws a critical exception.
  
  
• Write scalable, but don’t scale. If you’ve been doing web design for long enough, you know how to write scalable code. This doesn’t, however, mean that you must write code that scales from the get go, because you likely won’t have to. In our case, we completely uncoupled frontend and backend, and never looked back.
  
  
• Write uncoupled. I don’t know about everybody else, but when I use a class, I want to include that class. If I need to also include thirty-eight other classes so that inheritance and dependencies can be satisfied, I’d rather give up coding and take up farming. With one exception (the aforementioned security class), our classes have no direct dependencies on each other.

So, there you have it. Our framework—lovingly called Inferno—has been running behind the scenes for a year and a half. It consists of a completely uncoupled set of about 25 independent classes that power all our sites. It provides scalability—both vertical and horizontal—by implementing a simple, but robust, service-oriented architecture that powers eight different applications through three different distribution channels (web, client-side and iPhone). It is uncomplicated, and can be picked up by a good developer in a day or so (and I speak from personal experience).

You may be wondering why we haven’t published the framework, or made it open-source. The answer is simple: there is nothing to publish. Most of the techniques that we have created specifically for it, we have already discussed and published in various places, such as my blog or php|architect. You are, of course, free to use them (and, hopefully, improve on them).