What's the ROI of using a build tool like ant or nant?

Question

To me this sounds like a really stupid question.

Why would you not use a build tool?

However, I need to explain my co-worker why he should be using a build tool of some sort.

He's getting really into the idea of working as a team with more programmers, but he isn't understanding the bigger picture of what needs to change in the build process in order to work with a larger team; (i.e. defensive programming/unit testing your code, having a bug database, programming modular libraries, and using sub-repositories to store modules in version control.

This is a rather large stack of technologies that I need to prove the ROI of...so I figured I'd start with the ROI of using a build tool rather than just...say...clicking compile.

Answer 1

Ant isn't just obviously beneficial in every programming shop. How much integration is involved in your build process? What tool(s) are you using? Which CI server have you chosen?

The simple answer is that the ROI is high when Ant saves you time, and only details about and experience with your situation are going to be relevant when deciding how much time it will save you.

In our case, we use Nant to build our databases because numerous command line-level steps are involved with doing so. We do not use Nant on our .NET software because VS 2010 and TestDriven.Net provide far more context-sensitivity than any other build solution and our excellent CI server, TeamCity, natively understands the Visual Studio build process.

Answer 2

To get a valid ROI you have to have the cost of the investment and the cost of the savings or added revenue that the investments will bring.

For tools like Ant and Maven (I would use maven) you have no license fee, but you need to build skill on the tools, which may cost some money.

The key benefits for these automated tools are:

1. Accelerate on boarding of team members;
2. Document the build process;
3. Improve quality via automated tests;
4. Ensure consistent builds;

For each of this you have to put a price tag. You can argue that a good IDE will do the building and testing for you. But this will change from user to user. Lets say it takes 4 hours to get a new developer to have a valid build environment, and someone is helping. That is going to cost X, which would be severely reduced by a automated process. Add to that how much it cost of fix a bug (not all will be avoided by the build process, but let's say 30% are). These things are the cost.

Now compare that to how much your co-worker has to invest to learn the tool (which is the one time cost of using such tools). But I think that it's more fear than reason that bothers your co-worker.

ROI make more since when the person you are showing them to agree with the values being used. So try to use your past project cost to do this. In this case you can compare time instead of money. Projects can be severely delayed by people banging their heads on inconsistent builds.

Answer 3

First of all, build means a lot more than just compiling and typically involves steps like compiling code, compiling tests, running tests, running quality checks, packaging the code, assembling parts together, sometimes deploying, etc.

Secondly, it seems obvious to me that an automated build will always have a better ROI than doing the above steps manually on the long term (not even to mention that humans make mistakes, that you may not want to be dependent on the IDE, that you may want to run the build on another, possibly headless, platform, etc).

Thirdly, build automation is anyway an absolute requirement for continuous integration which is known to be a best-practice that everybody should follow (you want feedback as soon as possible, you don't want to let a problem go further into the system until the big-bang integration).

So for me, the question is not even about ROI, it's about sanity. Just in case, here is a little quote (see also Three Strikes And You Automate):

If there is one system administration truism, it is this: no simple sysadmin task is fun more than twice. If you find yourself doing a simple dull task more than twice, automate it.

Answer 4

The way I think about it whether it is your own business or working for someone else. If the tool can save you at least the money that was spent to acquire the tool, then it is a worthwhile investment. Keeping in mind that saving money can be related to time spent for

• planning (software or otherwise)
• design / development
• keeping records (eg. time to track history of bug / source / business admin)
• monotonous tasks that a tool can perform (backups?)
• concerning yourself with problems that a tool can do for you.

Don't forget that a tool generally requires initial training / learning that is a cost also. So if the tool is a once off, you may need to weigh up whether the cost of learning outweighs the cost of the tool.

Getting back to the basis for your question... As an example, if a build tool was $1000, your time is $100/hr. We will disregard tool training cost as we intend to use the build tool multiple times.

If you need to spend 0.5 hours with a tool to create a final build environment the maths says

Your cost with a tool = $1000 + (0.5 x $100) = $1050

If you need to spend say 12 hours to do set up the build environment manually

Your cost without a tool = 12 x $100 = $1200

Or, maybe an example that is a little more realistic, you can see 6 upcoming projects. Each project will take 0.5 hours to set up with a build tool, or 3 hours without.

Your cost with tool = $1000 + (6 x (0.5 x 100)) = $1300 Your cost without tool = 6 x (3 x 100) = $1800

It seems that the build tool in these scenarios would be seen as a worthwhile investment.

Hope this helps...