[Catalyst] Development environments and performance

[Jonathan Rockway]

On Wed, 2008-01-16 at 09:44 -0600, Dave Rolsky wrote:
> If it's fine that way then the problem is your development environment. 
> Really, I think you're _much_ better off giving each developer the most 
> powerful machine you can afford and having them do their dev work on it. 
> Developer time is usually more expensive than hardware, and sharing a 
> single machine seems like a way to spend more than you save in the long 
> run.

This is spot on.  When I worked for $COMPANY_NAMED_AFTER_A_MOUSE_EVENT,
we all (40+ developers) shared one dev database and dev machine.
Needless to say, this sucked.  When the system was working normally,
each page would take about 10-15 seconds to load (due to the fact that
we hit the database about 10 times for each page load no matter what the
page was; we couldn't cache this because "what if a user's account is
disabled? we can't wait 10 minutes for the cache to expire").  This made
development extremely tedious.  Fix a bug, wait 15 seconds, see the
mason error (all the code was in Mason templates; very few Perl modules
to be found), fix the error, wait 10 seconds, see the page, move on.
For. every. change.  (No automated tests either.  That was nice.)

The worst part, though, was that the sysadmins had no idea how to run 1)
linux 2) apache or 3) perl.  This meant that the dev system would be
down for *the entire day* at least once a month.  When it wasn't down,
Apache would run out of SSL mutexes or the OOM killer would do its
thing.  (Did I mention that the dev servers weren't located anywhere
near our offices, so keypresses over SSH would take over a second.)

Oh well, watching Youtube was more fun than working on that application
anyway.  (Interestingly, the solution to this problem was to keep hiring
more and more perl developers.  1000 people writing 1 line of code a day
is better than 1 person writing 1000 lines of code a day, right?)

Anyway, at my current job all the apps run locally on my laptop.
Working on them is quite enjoyable as a result.  Any database fuckups
only affect me, and since we all use different machines, we know that
our app is portable and easy to install on production.

The only bottleneck is having to write mailing list posts like this
one :)

Regards,
Jonathan Rockway
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080116/f0deb21a/attachment.pgp