I'm not the only one with build system problems, Charles Miller sounds like he's covering familiar territory.
"Mostly good enough" is a powerful and evil demotivator. We inherited a web application from a big-5 consulting firm who shall remain nameless with a terrible, terrible build system requiring the developers to manually track changed files so we could build a tarball of them and copy that to testing environments, and eventually production. The configuration files had to have the changes manually applied to them, and this is all amidst an application with no visible architecture undergoing heavy development.
So in a weekend of hacking, out with the old and in with a new "path-of-least-resistance-so-we-can-make-some-progress" build system. It was "good enough," and we quickly fixed a lot of the pain points (development went smoother, we could troubleshoot better, and within 30 days the application wasn't crashing twice a day).
One year later, the system remained mostly in place since it had never again become a big enough fire to be worth fixing. Now that the app/project has a reputation for running pretty smoothly and having a good development team, new developers to the project shake their heads at me, thinking "What on earth was he thinking doing this?" I can only point them to our "HistoricalBuildNotes" wiki page for some background. I'm using their complaints and troubles (why do I have to make my changes to 2 different config.xml files, and why on earth is the source code in the WEB-INF directory?) to build up my motivation to replace the thing.
On the bright side, what I took away from that gave me tons of insight as to what a web-app build system should support, all of which I used to create a new system to replace one on another project in our department (a build system which, while it worked much better, was even more inscruitable than the first, if that's possible).
It helped me a lot to think of it as a seperate entity; what are the requirements? what do I want it to do that it doesn't? That, while keeping in mind tranparency and discoverability (more) eventually drove the design of something better.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: