On Tue, May 29, 2007 at 09:18:23AM -0400, Lew wrote:
> still often "end up with some pretty bad database access"; best case is you
> get a subset of the database system's power for an increase in application
> complexity. This is the irony lost on the proponents of these frameworks:
> "If you work really, really hard it'll save you effort, except in
> development or maintenance."
Well, maybe not. Remember, there are lots of ways to optimise your
code design. One is to design for the tools you have and know how to
use. If you have a bunch of developers who know Beans (sorry, I
couldn't resist), and you have six weeks to deliver functionality
that oughta take six months to do properly, then you just throw
together the things you know how to do. This makes for much less
good code, of course, and will cost in the long run. But for
immediate-term problems, it might be a good trade-off. (There are
plenty of companies who then never do step two, which is to throw all
that away and do the job properly. But that's just bad management,
and is not an argument that the original trade-off was necessarily a
bad one.)
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The plural of anecdote is not data.
--Roger Brinner