Thanks to the modern Integrated Development Environment (IDE), building software is easy. I'm not talking about writing software, that will continue to be challenging for a while yet, I'm talking about the actual compile step. Let's use Visual Studio as an example: Not only can you compile your code, but with the use of pre-build and post-build steps you can put all the work needed to build your software right there in your project file. What could be more convenient? In fact, it's so convenient that many developers never even question whether it's a good idea or not.
Building software well is hard. A comment last week from Christopher Painter at DeploymentEngineering.com reminded me that I've wanted to write this post for awhile. It never ceases to amaze me that developers will go on and on about "loose coupling", "high cohesion", and "inversion of control" and then turn around to violate all those principles by coding deployment instructions into their project files. We talk about loose coupling in development because it gives us flexibility and makes maintenance easier down the road. Aren't those good principles in a build? High cohesion is a nice attribute that essentially means "things that are alike are together". Hmm, I'll take a shot of that in my build. Don't even get me started on Inversion of Control. The fact that a developer would accept the added complexity of an IoC container and then balk at the idea of using a separate NAnt script or MSBuild file for their build stuns me.
Here's a radical thought: Your build is software too. Your build should adhere to the same principles that your software does. Your build needs to be maintainable. Your build should be self-documenting. Your build should provide good feedback to the user. Your build should be easy to run.
So take a look at your build today and see if it represents your development principles. Practicing what you preach (and doing so consistently) is the hallmark of a Big Swinging Developer.
My new theory is:
If it's available from an IDE, developers will take it on. Hence, you can convince Java developers to have a go at an Ant build because there's usually IDE support. NAnt? Nope, there's no native support in Visual Studio.
I find it hard to get .NET developers working on the build. Java developers will approach it. I don't think they'll refactor build files unless there's a plugin.