Do you have lack of consistency and understanding how your software is built? Does this equal varying degrees of success – both in each build and in changing or adding new features to it – and lack of confidence from your developers?
Did you roll your own build process that’s "the best thing since sliced bread" but only a select few developers really know how to use it? Do you dedicate resource to tweaking or fixing your build scripts?
To put it another way: are all your developers building the software using the same scripts your continuous integration environment is using?
What’s Wrong with the Above?
I believe building software should not be a complex process. It should be rare for a developer to delve into the build system to tweak it.
I also believe that because there are common parts to building – source code, tests, packaging – that there is little need for a "shop" to be going it alone and building something vanilla just because they can.
Essentially, building software comes down to performing a few tasks regularly and consistently; a developer will need to build, test and package regularly. Rarely do they need to work on the build system (unless something’s broken…).
With this in mind, should developers therefore not be able to perform these tasks without thinking about it? Wouldn’t it be beneficial to us all – as an industry even – to be able to go anywhere and build most software the same way because the requirements for building doesn’t differ?
I’m not making a case for never "rolling your own", I’m merely trying to clarify that those who do may not need to do so. Granted, some scenarios warrant custom build scripts and the like.
The Ant Perspective
With Ant, building means code. It means logic and that invariably doesn’t get the same strictness and quality applied to it like your everday Java and its counterparts. This means the build scripts quickly become convoluted, poorly maintained due to a "get it working" attitude. Unless a good/strong developer is dedicated to maintaining and scaling the build scripts, the job gets shared around and each unique developer’s perspective warps the overall goal.
Most software building is just a set of tasks that are repeated for each build. Compile this. Package this. Distribute that. It doesn’t make sense to have a human do that: computers are here to do the mundane stuff.
The Maven Perspective
With Maven, you just provide metadata. The framework provides the logic in a consistent and predictable manner.Don’t you want developers to be concentrating on writing code: fixing bugs, implementing new functionality and improving the quality of the product.
Maven allows one to have artefacts produced properly, with correct structure, metadata and naming conventions, that mean a developer – or person – doesn’t have to think to do it. These artefacts are of production quality, always.
Consistency means one does not have to think about how or what they’re going to do when it comes to the build process.
If you’re a foreman building me a house and I say "build it this way please" and hand you a 3000 page instruction manual on how the Tudors and Stuarts built their houses prior to the great fire of London, you don’t say "Yeah sure!" you recoil because years of history and experience has taught you otherwise.
Is it fair to say that developers need to spend time fixing bugs and implementing new features and not spending time tweaking the bugs in the build system? Would you be happy to pay for a plumber to spend time fixing his toolbox instead of correcting that leak? If this isn’t acceptable, then you can understand why businesses might not want to spend the time (money) correcting your poor house keeping.
Quality Across the Board
Consistency breeds quality. A scenario where best practice is common, reliable and well-established norms are instinct encourages going the extra mile to write better software. In contrast, an unreliable, poorly designed and maintained mode of practice breeds contempt. Building your software is part of all of this and is a contributor to success or failure.
I’m by no means saying "blame your tools", just that better-quality tools can contribute to improved output.
Environments are a Different Beast
Environments have numerous issues whereas development seems fine; "Works for me" is far too common a response for when someone has to investigate a problem in a given deployment target.
The big wins with Maven
Consistency across the board. It shouldn’t matter where you go or what customer project you’re on, you build, deploy, package and distribute artefacts the same way. Imagine a situation where developers can go anywhere and "pick up where they left off": start developing within minutes.
Junit testing – maven bakes testing from the beginning, which brings it to the developer’s mindset at the right points (i.e. always)
Greatly simplifies build processes: it doesn’t become a matter of how, but when. Developers learn a simple set of commands that never changes
Dependency management is excellent: simplifies set up of projects, developers can get up-and-running within minutes
Packaging is excellent. Multiple formats supported, from JARs, EARs to Zip, TAR etc and it is not left to the understanding and implementation of the developer implementing the build script
Industry recognised: we don’t have to have developers "get up to speed" because maven works the same everywhere, developers just remember a few goals to tell maven what to do: compile, clean, test, package and they’re ready to start coding
Have your developers building code and understanding how it’s built, not programming by coincidence. Don’t be in a position where your developers are relying on their IDE to build and having a separate process entirely for your CI!