[Catalyst] Re: Development environments and performance

[Dave Rolsky]

On Wed, 16 Jan 2008, kevin montuori wrote:

> DR> I'm thinking that a sane budget is $2,500 per developer machine
> DR> (with monitor). Is that unreasonable? Do you really need to save a
> DR> few hundred bucks on ram?
>
> it's not so much that it's unreasonable (though the extra $700 apple
> charges for 4 instead of 2 GB certainly is) as unnecessary.  actually,
> the "at least" part made me chuckle.  i've honestly never felt
> constrained by 2 GB, but whatever.

That was "at least a dual core with 4GB", not "at least 4GB of ram". I 
just meant "fast proc with more ram than you think you'll need". Ram is 
cheap, except when you buy it from Apple, so it doesn't hurt to have more.

> DR> This is what automation was invented for. At several past positions,
> DR> I've set things up so that development consisted of checking out the
> DR> source and running a "set up my dev env" script that created/updated
> DR> the database, inserted test data, set up any servers needed, etc.
>
> so resources should not be shared in a development environment at all?
> everyone gets their own oracle server *instance* (not database)?  it's
> one thing to crank up a new database and slap in a schema, something
> else entirely to maintain a separate instance of oracle.  i've seen
> grown men cry trying to install it (and get the instantclient libs,
> tnsnames.ora, &c working).

Well, I'm sure Oracle is the devil. OTOH, once you figure out how to do it 
once you can automate pieces of it and document it. My assumption is that 
each developer is running the same OS. If not, that obviously makes things 
more painful.

> DR> That said, I think good developers should have some minimal sysadmin
> DR> skills, and should be comfortable setting up a DBMS or LDAP server on
> DR> their own machine, and difficult installations can be scripted.
>
> that's naive.  not that i don't agree (i do, very much so).  the sad
> reality is that we're having a difficult enough time finding developers
> (for a $75k/year, 2-4 years experience position) who can even discuss
> what LDAP is, never mind try to configure it.  maybe everyone in your
> shop is a reasonable sysadmin, but that's not what i've seen.

In past jobs, yes, everyone has had at least enough skills to install 
stuff, and those with more skills helped those with less. Again, once it 
was done once it was documented (well, once per OS in our case since some 
folks used Ubuntu and others liked OSX).

I don't think there's anything naive about saying good developers should 
have some sysadmin knowledge. That's just part of my definition of "good". 
Of course, I wouldn't expect good developers to be found for $75k ;)

> DR> Presumably that depends on how many devs you have. However, I'd be
> DR> going nuts if I had to deal with other devs changing the database
> DR> schema, or even just changing the state of the data while I'm trying
> DR> to develop against it.
>
> presently, development (database and LDAP) schema changes are managed by
> the release manager (which makes sense if the changes are going to end
> up in integration, test, and production).  developers have access to
> their own copies of the schema and data that can be refreshed at their
> leisure, but DBA services are provided centrally, so backups (and
> restores) "just happen" on sandbox databases.

I don't need backups for my dev database, I need to be able to change it 
though. Again, I see this as a standard part of rapid/agile development.

>  -- code that's been tested by the developer in development will almost
>     always run in integration because the versions of the libraries are
>     consistent.  furthermore, there's a good understanding of what's
>     required to deploy code that's been written against the development
>     environment.  less so when people tell me that "it runs on my
>     machine, i don't konw why it doesn't run in integration."

OTOH, it makes upgrading anything for a particular line of development 
very hard.

>  -- experienced developers new to the environment waste almost no time
>     trying to futz around getting all the working parts configured
>     correctly.  we run a setup script and volia, their databases, ldap
>     instances, apache sandbox, SSO configuration, firewall
>     configuration, &c. are complete and correct.  when upgrades are
>     done to any of the software, these are mostly transparent to the
>     developers.  and backups (and recovery!), security, access from
>     off-site, redundant power, &c. are all included free of charge.

You can run a seutp script on a separate machine too. What's the 
difference?

>  -- junior developers end up in the middle of a working environment
>     rather than frustrated trying to piece together their own bit by
>     bit.  i realize that our shop is a little abnormal in that we're
>     higher ed and end up with our share of just-graduated and
>     work-study types, so this point is actually very important to me.

See above.

> note that just because an environment is provided doesn't preclude
> cranking out some code elsewhere.  but it does provide a proving ground
> *before* commits are made to VC.  this almost 100% eliminates the "it
> works on my desktop" complaint.

That's what integration environments and branching are for.


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/