Andrew Sullivan wrote:
> 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.)
I completely agree. And laugh at your pun.
My post had to do with the ideal; yours focuses on the pragmatic.
If your one-off approach employs standard patterns (like JavaBeans) and
programmers steeped in a culture of excellence, the refactoring to a
full-blown architecture is much less painful.
My own practices are slighlty schizoid - I aim for technical elegance but
frequently make compromises for expediency.
--
Lew
