Developers Want to be (Successful) Fighter Pilots
Jeff over at Coding Horror relays a metaphor from Roger Sessions at MSDN describing how the technically inferior F-86 consistently beat the MiG-15 in dogfights and how it relates to developers. The answer? Maneuvering the F-86 was easier on the pilot, resulting in less fatigue over repeated maneuvers. Thus, a developer or project that iterates faster will yield better results than one that focuses on quality.
A man would do nothing if he waited until he could do it so well that no one could find fault. ~John Henry Newman
Regardless of the accuracy of the metaphor, there’s one thing I’ve seen in almost every project over the course of the last 15 years:
When a programmer thinks something is finished is never the same as a project manager or client. It doesn’t matter how much planning you have, if programmers are rushed or relaxed, or how much testing occurred. There are many types of programming projects (server, client-server, web, computation, etc.), and each one has its own idiosyncrasies; but, something is always forgotten, misinterpreted, corrected—or, the client just changes their mind. Revealing these disconnects sooner will help minimize the number of surprise moments at delivery time, as in the swing-set example.
The big benefit of quick iterations is the feedback process. Getting feedback sooner than later is always good, assuming the client can accept that what they see after an early iteration is not representative of the finished product. The quick feedback process applies to the developer as well since automated tests minimize the refactoring and validation time, allowing you to handle change with minimal pain.
As Jeff says, “when in doubt, iterate faster.” It’s not always that simple when working with external clients, but successful fighter pilots developers know that without agility, it’s tough to be successful—especially with web projects.

Tyrant is a "meta" Rails application designed to run other Rails applications.
Recent Comments
In my quick testing of this it does still work if you chain items after the cache name:
Category.top_level.other_scope
But important to note is this will still make a call to the database, it will not take advantage of the cache. Of course the actual scope, in this case
find_top_levelis unchanged and so you can still do any chaining with that, which also of course won’t use the cache.As a final note though if you’re needing to do much chaining, caching in this way may not be best for your particular situation. The idea of the cache is if you need to retrieve the exact same result set over and over again, and it rarely changes you shouldn’t have to hit the database.