
Develop for Maintenance - nreece
http://geekswithblogs.net/robz/archive/2008/06/11/develop-for-maintenance.aspx
======
Tamerlin
This makes so much sense that it amazes me how many times I've run into shops
that haven't even bothered to TRY doing this.

Most of the shops I've worked at that have existing systems have setups that
require days of effort to get working. One developer I ran into couldn't get
the stuff he'd written to compile on anyone else's machine, so his method for
deployment was to build it, jar it up, copy the jar over to the target
machine, unpack the jar, and clean stuff up.

Needless to say, he'd been working on a product for that company for around
six years, and not only was it not finished, but no one, including him, could
explain what it did to anyone.

------
makecheck
I think the article sums up some important steps, definitely problems I've
seen on other projects before.

One thing I would add is to regularly repeat the "wipe, checkout and rebuild"
process, especially as part of releasing the product. It's scary if someone
builds software out of their messy work-area and releases it for "production",
instead of using a clean tree in the middle of nowhere. It's just too easy to
forget to check something in that matters.

~~~
andrewf
Something I settled on personally is:

You should have a standard build environment in a virtual machine.

This comes pretty naturally if you're doing nightly builds and aggregates 90%
of any build.txt into: copy this VM from the DVD to your hard drive and fire
it up.

Of course, you should maintain a full build.txt anyway. Having a standard
build VM which nobody could rebuild from scratch brings its own set of
problems.

