In addition to initial productivity, maintainability and enhanceability, 
including by future people who won't be you, is a huge consideration.

A framework can probably either help or hurt that too, depending on how 
good it is.

Jonathan

Tim Spalding wrote:
> Casey: "I think it's extremely hard to appreciate both the advantages
> and disadvantages of a framework if you haven't done a bunch of stuff
> both with and without one.  ...  Tim can be at least as productive
> writing PHP by hand as I can using Django, but most of us can't be
> Tim.  Most of us need to exploit every unfair advantage and shortcut
> we can find."
>
> I won't disagree with Casey. We see it from different angles, but
> Casey has more experience at both "ends" of the problem, and an
> informed, balancing approach is best anyway. Much depends on exactly
> what you're doing and what resources you can call on—not to mention
> what you're used to. Mutatis mutandis you're trading application speed
> and for coding speed, with arguments on both sides as far as
> scalability. Since application speed is just not an issue for most of
> what most people do these days, gaining developer-coding speed is a
> good trade.
>
> I see errors in both directions. There are some CRUD pieces to
> LibraryThing that took *way* too much time to do because we did them
> all by hand. Casey's introduction of a Django framework there was very
> smart. At the same time, I think Twitter got stuck in RoR. When a web
> application is so extremely simple--it does basically one thing!--you
> might as well write that as "close to the machine" as possible.
>
> Tim
>
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu