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
===================================================*/
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
