Category: software

Caching is a Workaround, not a Solution

Like every website that deals with traffic spikes, the one I’m working on these days does a lot of caching. This past week I’ve spent a lot of time reviewing the caching code as well as tuning the database, to get the site working efficiently on a newly upgraded virtual private server.

The following occurred to me: as wonderful and necessary as caching is, it’s fundamentally a workaround. The core problem is having insufficient resources. Given enough CPU and memory, you wouldn’t ever need to cache. It’s when those resources are insufficient for a particular traffic load that caching becomes immensely helpful. That’s why it’s a workaround: it practically addresses the problem, but it doesn’t really solve it. And it’s not a perfect solution: simple caching mechanisms usually introduce a lag time in the currency of content.

Why does this matter? Because caching shouldn’t substitute for efficient code. That is, uncached operations should still try to make the best use of resources as possible. Otherwise, caching turns into a panacea, luring you into a false sense of security about how well the guts of the application really perform. Ideally, caching should always be added as an afterthought on top of already well abstracted code.

Maintainability Pitfalls in PHP

Tim Bray makes this prediction about PHP for 2008:

PHP will remain popular but its growth will slow, as people get nervous about its maintainability and security stories.

I share Tim’s love/hate relationship with PHP. It’s definitely a powerful and easy language. But,

… speaking as an actual computer programmer, I really dislike PHP. I find it ugly and un-modular and there’s something about it that encourages people to write horrible code. We’re talking serious maintainability pain.

I’m seeing this right now in some code I’ve recently taken over. The previous programmer was quite skilled and did a great job, but it’s clear there are some areas he had to write quickly and hack together. The flip side of PHP’s ease of use is that sloppiness accumulates very quickly when you’re doing things in a hurry. To some extent, that’s an unavoidable aspect of a growing codebase. But there’s also specific things about PHP itself that foster disorganization and unmaintainability:

* The lack of namespaces. This makes it hard to quickly locate a function or class definition. Classes can be used as namespaces, but that’s a hack, and leads to ugly un-OOPish uses of classes. PHP could really benefit from packages or modules.

* While PHP5 has vastly improved its object functionality, it often feels like the developer culture remains mired in a function-oriented paradigm. PHP’s relative ease of use and wide availability on commodity webhosting has produced a huge pool of developers whose skills are pretty wide-ranging. The low end of that tends towards hacky, function-oriented code that simply “gets the job done.” I’d like to see more thoughtful discussion on PHP sites and forums about object design and philosophy, about when to use functions and classes, and about how to mix them up harmoniously.

* Having a library of thousands of built-in functions in a global namespace with little rhyme or reason to their naming doesn’t exactly provide a great model of maintainability.

* extract() should die. Die, die, die.

* There’s not much agreement about OOP performance: some insist that heavy usage of some OOP features slows PHP down a lot, so you should avoid them whenever possible. Which not only is plain dumb but leads to deliberately confusing and half-assed uses of OOP in the name of better performance.

Maintainability is a matter of discipline, since you can write sloppy code in any language. That aside, PHP does make it extra hard to keep things orderly. I think CakePHP is a step in the right direction, though if you’re going to use a strict MVC architecture, you might as well dump PHP and just go with Ruby on Rails or Python.

Amateur thoughts and ambitions

One of the better things I’ve stumbled across this past year is Larry Lessig’s talk, How creativity is being strangled by the law.

The piece makes his usual argument that copyright law stifles innovation in the age of new media. Most striking to me, though, was the part where he uses the phrase “amateur culture.” He explains, “…I don’t mean amateurish culture, I mean culture where people produce for the love of what they’re doing and not for the money.” He uses the term to describe the activity of “kids” (?) creating their own remixes from existing media.

I can remember another amateur culture that’s now largely disappeared. Back in my teens, modem-based bulletin board systems (BBSes) fostered a rich “read-write” culture for amateur programmers. Most of us did not work in technology; after all, the commercial Internet hadn’t been born yet, so the computing industry was much smaller and more obscure. A career as a programmer seemed like a mysterious and rarefied thing to me back then. The coders you met on BBSes were often people who simply liked to do programming in their spare time.

These systems allowed us to circulate public domain source code for fun games and useful applications written in BASIC, Pascal, C, even assembler. We hacked on existing code to get it to do what we wanted, trying to figure out ways to push the limits of our little 8086 processors and 640K of RAM. We mingled regardless of our level of knowledge, beginners and experts alike. We had friendly user meetings in diners in Brooklyn and Manhattan (I lived in NY at the time), where we chatted about home-grown upgrades and discussed how to link up to the nation-wide discussion networks that existed then.

It was amateur culture at its best: lots of exchange, circulation, and cooperation happened all the time. But it was definitely not amateurish. Many were extremely capable and knowledgeable coders.

Today, there are still people who code just because they enjoy it, but the amateur culture and its community hardly exist anymore. Beginners on web forums are more interested in what they need to know in order to land a job, rather than in coding itself. Even open source projects tend to be dominated by career professionals; read any public mailing list and you’ll see how unhelpful they often are to amateurs who want to get involved. One reason I like python is that the project makes a genuine effort to connect to the sensibilities of amateurs. But even its forums are littered with snarky individuals.

All of this is largely due, I think, to the ideology of professionalism, which convinces us that having a stable career is the pinnacle of achievement. It damagingly equates amateurs with dilettantes. That’s why one of the first things we ask in this country when meeting a stranger is, “So what do you do?” By which we really mean, “Tell me what you do for a living so I can know who you are and whether you’re worth talking to.”

In 2008, I resolve to be more wary of this ideology and its negative effects. I want to embrace being an amateur in the various things that I do. I want to think less about careers and focus more on how to best spend my time doing what’s important to me. And I want to find more amateurs to hang out with as well.

Software is an Art

Today a blogger named Damon Poole wrote a short post titled, “Designing Software is the same as Predicting the Future.” It resonates with my post from a while back on whether “software engineering” is the right metaphor for writing code.

The essential problem of coding is to deal with the unknown as best you can. Software is made to solve a problem, but the more unique the problem, the more difficult it is to draw upon existing knowledge to create good solutions. Unknowns force you to make guesses. Educated guesses, hopefully, but guesses nonetheless.

This is why I’m in the camp of those who believe that creating software is an art. It’s an endeavor that wrestles with the unknown. This artistry is highest when you find yourself asking, “How do I do X?” and there don’t seem to be any pre-packaged answers you can look up in a textbook or simply google.

Paradoxically, once the software is written and refined, the unknowns are removed from the picture. Art largely disappears once the pure functionalism of operational software emerges. I think this is why many good programmers have short attention spans, get bored, and tend to jump from project to project. They crave the excitement and gratification of facing the unknown. But this is always ultimately ephemeral.

HTTP + XML do not a RESTful interface make

I’ve been stumbling across criticisms of the un-RESTful design of Amazon’s new SimpleDB service. Worth reading in particular is a piece by someone named Subbu Allamaraju, who seems both smart and accomplished. He did a quick rewrite of the API in his post, A RESTful version of Amazon’s SimpleDB. It’s a great example of how clean URLs can be when a bit of thought is put into them.

And people should also read it to clear up a popular misunderstanding about REST. I’ve already given it away in my title: HTTP + XML do not a RESTful interface make.

As Roy Fielding’s dissertation chapter lays it out, a REST architecture should follow the abstraction of “resources” from the “connectors” that perform operations on them. The HTTP protocol happens to be able to do this nicely: URLs refer to resources and the GET/POST/PUT/DELETE methods manipulate them. However, this isn’t inherent or automatic: you have to use its vocabulary properly. SimpleDB is a perfect example: it violates the principle that resource identification and operations should be separate. The API embeds operations in URLs.

So yes, it uses HTTP and XML. But no, those things alone don’t make it truly RESTful.

REST is certainly a huge step forward in enforcing cleaner abstractions, though in Amazon’s defense, it’s obvious why they choose to design their API the way they did. The URLs for SimpleDB have the same structure as those in ECS; consistency was probably the goal. So yes, it’s a conservative move that forward-thinking coders are turning their noses up at, but it’s also one for which existing developers will probably be grateful. Rant all you want about the evils of non-idempotent GET requests… for Amazon’s customers, the old API style feels familiar, and means one less new thing to get used to, or to learn.