As promised, as the election is over, I will get back to blogging non-political things.

And hey, I haven’t posted a continuation of my web frameworks presentation yet!

Good thing too because, if you don’t know, I’m giving a talk on that tonight at CBS Interactive (CNET) in San Francisco. Come see it or watch online at 7:30PM Pacific.

Software is about making choices

So the second thing is Challenges and Choices. When I wrote my Rant on Rails, some people jumped on me, but I don’t think they gathered the basic assumption I was coming from.

It is not so much an assumption as a fact: when you develop software, it is about making choices. It is about tradoffs. You can do “A” but you can’t do “B.” You can’t have both A and B. I know it sounds like it’d be great and I’d like to have my cake and eat it too, but really, I’d rather be playing Counterstrike—I only have so much time to devote to writing software, that software can only execute so many times, things like that. I can’t make something do everything.

One example of that is in design patterns.

Design Patterns

“*sarcastic* “Quicksort must be a fucking design pattern.” #zendcon #tcfc” —elazar

“”No matter what they do, they sort of fall into a fucking trap.” #zendcon #tcfc” —elazar

“”there’s no difference between design patterns and porn” – tychay” —auroraeosrose

“”There is no difference between design patterns and porn” — @tychay #zendcon” —dcousineau

“From @tychay: “There really is no difference between design patterns and porn”” —EliW

I used to give a design patterns talk. When people put “design patterns” on their resume, I like to ask them a particular question—especially when their background is J2EE or they say they know design patterns. The question I like to ask is define design patterns—what does that term mean? I’d say about 90% of the people who put that on their resume bomb that question. It’s actually not an easy question. As soon as they answer it—they give me some sort of pseudo-book definition—I tear into them. I’ll give you an example:

The typical thing that they’ll say is, “Oh! A design pattern is this code thing that solves…umm…a problem.”

And I’ll go, “Well, shit.” *laughter* “Quicksort, right? That must be a fucking design pattern then.” *laughter*

And then they’ll say, “Well no. Quicksort isn’t a design pattern.”

Then I’m like, “Well, explain to me how it isn’t a design pattern. Your definition is that is solves a problem—which I agree, design patterns do solve a problem—but obviously that’s not a sufficient definition for design patterns.”

You get where I’m coming from? And the reason isn’t…

And then they’ll say something like, “Well, you know. It doesn’t have like… It’s not an algorithm!”

“Umm…Yeah. So then design problems are something that solves a problem but isn’t an algorithm. So, code versioning! The practice of code versioning solves a problem and it’s not an algorithm clearly! (In fact this is what’s called a “best practice.”) So how is a best practice not a design pattern?”

See no matter what they do they fall in a fucking trap. *laughter*

So I’ll give you my definition of design patterns. Well my honest-to-goodness definition of design patterns is to quote a famous Supreme Court justice when he was talking about it: He said that he’ll know it when he sees it.

Actually, he was talking about porn. *laughter* But there is pretty much no difference between design patterns and porn so we are all okay with that.

But [design patterns] do have these qualities. The first thing is, it has a name. You have to give it a name or it isn’t a design pattern. Why? It is a vocabulary—when I speak to you, I could write it for you; or I could give it a name and you could write it for me. You see, I’m an architect and I don’t like to code so this stuff really helps! The second thing is it indeed does solve a problem. The third thing is it’s independent of the code that implements it. But the last and most important thing is—that separates a design pattern from what we would call a “best practice” is—it has consequences.

See that one is the one that is typically missed by almost any candidate I interview. What does it mean to “have consequences?”

You see even when I say that they’re like, “Oh yeah!”

And then I go, “Well, what does consequences mean?”

And then they sort of fall on that. *laughter*

The answer is it’s a tradeoff! It’s programming and programming is about tradeoffs. You can do X and not do Y.

An example of a design pattern in web design is if I said “breadcrumbs” and I said “tabs” you know what I mean. So it is a vocabulary word. They solve a problem—the problem of navigation on your website. They are independent of the code that implemented it:I didn’t tell you the HTML—HTML that implements tabs varies from Apple.com to Amazon.com.

And finally, it does have consequences: which one you use depends on those consequences. For instance, if I wanted to navigate horizontally and shallow, then I’d use a tab pattern. But if I need to navigate too far horizontally, the pattern breaks down and it becomes vestigial like in Amazon—there are too many sites there. And, if I need to navigate deep, then I’d use breadcrumbs. But you wouldn’t use both because the consequences of both is screen real estate, user confusion, etc.

So those are the consequences of a web design pattern. So apply that to programming and you have programming design patterns.

And why I mention this is because I want to mention that whenever I rail on Rails or rip on your framework, every criticism is coming from this concept of There are consequences. When you use a framework, you make a choice. When you adopt a framework, you adopt all the choices that that framework designer has adopted—so you have to be very careful in which framework you are going to use.

And if you are developing your own framework, those things are true too.

The Pareto Principle

“@paulwander and @rza you escaped #zendcon? losers! you missed the best keynote! (and now a @tychay talk)” —ijansch

For 99% of all frameworks out there, the biggest downfall is the Pareto Principle. This is also known as the 90-10 or 80-20 rule.

If you were to look at your codebase, and you were to go into subversion and look at how many times did that line get edited for each line and plot out the number of lines edited the number of times, you’d see a curve that looks like this. The horizontal is the number of edits and the vertical would be the number of lines that had that many edits or more.

In other words, about 90% of the lines of code have about 10% of your edits and out here only about 10% of your lines would account for 90% of your edits (and 90% of your time). Note that initially this isn’t true! When you first build your website, it is flatter like this, but over time, this function gets steeper and steeper. It depends how long your website is up—how much work you put into it. But eventually, for websites that are long-lived, will exhibit this behavior and this behavior is known as the Pareto Principle.

And it’s not just websites, it’s also a principle of economics, and almost every other thing you see.

What I’d like to point out here is this area is where frameworks are by definition—you can’t prevent this, itis just a reality. Frameworks write the 90% of your code that is only going to take 10% of your time in the long run.

That doesn’t mean you shouldn’t use frameworks at all, I’m just pointing out that you can’t get around it. But the other area—that 10% of the code that takes 90% of the time— is the part of the code that makes your website perform differently from all the other websites and products out there.

So, this means that the areas that are different, the areas that are trouble are the ones you are going to spend all your time on. When your site is long-lived, the advantage you get from adopting a framework will go down.

So one solution to using frameworks is to not program any website that you plan on maintaining, then go use frameworks! *laughter* This seems ironic, but in the next section that I’ll give you examples where this is the case.

The rock and the hard place.

“so is @tychay now ripping on porn and rails? #zendcon” —ibspoof

“#zendcon @TyChay is talking about Rails… oh god. RUN” —CaseySoftware

“”Fuck that shit, I can just go to SourceForge and type ‘recipe.'” #zendcon #tcfc” —elazar

“”Fuck that shit, I can just go to Sourceforge and type in ‘recipe'” — @tychay #zendcon” —dcousineau

“”I know it sucks as a security model, but fuck, it’s easy to install, right?” #zendcon #tcfc” —elazar

“”Fuck, I can download and install it… hell, I don’t even have to do that!” #zendcon #tcfc” —elazar

This brings me to the next challenge which is the concept which is the one of a “rock and a hard place.”

Here is Ruby *laughter* which is equal to Rails which is equal to frameworks in general (on the web). And then there is a rock here, and a hard place here. And Ruby has to navigate this Scylla and this Charibdis.

The thing is on one side you have “write it yourself.” So this is the Pareto Principle in action. At the point that the Principle kicks in, then you’d rather have the code written by yourself where you can handle the edits, because you are going to end up either ripping out the framework or keeping it and rewrite it.

So when you hear some guy interviewed at Twitter and he says: “Well the problem with Active Record, is that eventually you end up ripping out the very part that attracted you to it in the first place.” He is basically talking about this. Twitter is a long-lived site and now they are reaching the point that is forcing them to rip apart Rails.

The other area here is a story I have: When Rails first came out, a bunch of engineers at Plaxo were really into it, so I looked into it. They tried to convince me I was wrong and that Rails is the shit. *laughter*

Because you know me, I don’t believe anything is the shit. I was very attracted to things like Active Record and its concept of CRUD—that’s “create read update delete. To simplify all data access into those four concepts and the building of this stuff in the REST style via Fusebox methodology in order to handle all the resources.

But then I stopped and wondered: how is all this going to really work? I was working on a tutorial—basically a recipe database. I was very impressed. I build everything in about twenty lines of Rails—everything. I was like, “Wow! Twenty lines built me a shitty recipe database.” *laughter*

If I were to do this in PHP, it would probably take me about four to six hours—I’d have to set up MySQL, I’d have to configure PHP and Apache, and blah, blah, blah. That’s pretty impressive to do in 15 lines of code what took me four hours. Of course the Pareto principle kicks in…

On the other hand, I was like, “Fuck that shit!” *laughter* “I can just go to sourceforge and type ‘recipe.’” *laughter*

And that’s what the rock is. The rock is download. And what I mean by this is—think of the internet today. Think of things like Wikipedia (or Wikimedia: the app that runs Wikipedia). Think of things like WordPress. Think of things like Phorum—I know for you security people it sucks as a secure application, but fuck, it’s easy to install, right? *laughter* Think of CMS’s—there are a zillion—take a pick and choose your poison. Think of Trac when you are doing internal source code viewer and bug tracking system.

Think of all of these and say: “Ruby! Fine! I can do all these. I can build a WordPress in like a couple weeks—and to rebuild that in PHP it might take me a year.” But Fuck, I can download… Hell, I don’t even have to do that. Most hosting services have a button that you can click on that says, “Install WordPress” and I click on that and I’m done! *laughter*

And maybe you say, “That’s fine for those things.” But then think of how many commercial websites are on the internet that are actually powered by WordPress, or by Wikimedia, or by Phorum. When you stop and think about it, the download is a huge thing.

Ruby is making it easy to develop the sites that have been already been developed, but it is not necessarily making it easier to develop the websites of the future. And maybe at that point, the Pareto Principle becomes the determinator and we meet the hard place.

So if you are choosing a framework in general, you should be wondering whether it satisfies this sweet spot—this Jason and The Argonauts between this Scylla and this Charybdis, this area between the pareto principle and the download.

I’ll finish this section in a future post. 🙂 Just come to my talk!