This is the Ten Minute Build rule in James Shore’s and Shane Warden’s book The Art of Agile Development and it’s easy to see why this is a good idea because builds that don’t run easily are both frustrating, which lowers moral, and burn project time shoveling your company’s money into some metaphorical furnace.
If you build takes more than about 10 minutes there are a couple of things you should look at. The things to consider are tooling and infrastructure, which in plain English really means: do you have a dedicated build machine and are you using the right tool set? Getting a dedicated build machine shouldn’t be too hard as there is a cost benefit here: a developer’s time verses the cost of a virtual or real box, whilst many of the tools you’ll need are open source: Maven, CruiseControl / Hudson, GIT/Subversion etc.
If you already have a dedicated build machine and are using all the right tools then the next thing to look at are your unit tests. Builds that include lots of “end to end” or integration tests are usually the culprit. End to end tests are useful in that they prove your classes will work together, but your main testing thrust should be your class’s full set of isolated unit tests covering all necessary cases and edge conditions.
This is because end to end test usually involve setting up and tearing down some external service such as a database. Some say, that you don’t really need any end to end tests, but I think that you do as you need to prove that your classes will work together. So how many integration tests should you use? I like to aim for about one or two per scenario, but only if I’ve got a large number (say 10-20) unit tests per class to give me confidence that everything will work.
Some time ago, I mentioned the FIRST Acronym (taken from Bob Martin’s Clean Code) where tests should be FAST, INDEPENDENT, REPEATABLE, SELF-VALIDATING and TIMELY, which is a very good starting point when reviewing unit test performance.
Being pragmatic, there will be those applications that will never build within 10 minutes. In this case consider splitting your program up in to smaller modules as recommended by the Maven builds manual. Ask your self whether or not you’re building database access classes into the same JAR file as your business logic or presentation code and if so, split them up. You could take this one step further, and create a distributed parallel build environment, but be careful here you may unintentionally break Agile’s ‘keep it simple’ rule.
Reference: The Ten Minute Build from our JCG partner at the Captain Debug blog.
Related Articles :
