One of the benefits you get with consulting is that you get to see a variety of applications, processes, and in agile projects, different build pipelines. I take the developer loop very seriously, because how quickly you can get feedback determines how quickly you get serious things done. Different testing strategies are an important way of improving the amounts of feedback (as long as you can still write meaningful tests). Another technique is the ease with which you can configure various libraries, integration points and environments. Even splitting the build into various stages where failing earlier is more appropriate can help you get better feedback.
The ultimate feedback loop I’ve seen in Java is the “change-compile-run test” loop. Anything more and you will decrease your feedback cycle and adversely affect how fast you can develop. Anything less than this is unacceptable – skipping the “run test” stage doesn’t do anything to validate that what you wrote actually works. On a side note, in an interpreted language, the loop is even tighter, simply being “change-run test”.
J2EE’s “Enterprise” Feedback Loop
I’ve worked on numerous J2EE systems that were all business successes. As a developer though, it still makes me cringe thinking about the feedback loop, and how long it takes to make a change to a class, or one of many, many XML files, jar up something several times, and then actually test it.
Optimising Your Build Loop
Visualising your build process is an excellent way of seeing exactly how many hurdles you have to go through to get any decent feedback. Even better is trying to work out which things you *really* need in a build and removing anything that just doesn’t add any value. I try to aim for the simplest and fastest feedback that you can get using the above diagrams as the ultimate goal. Give it a go!
You can actually go one better in Java… there is a plugin for Eclipse that does the “run-test” part every time you save. Saving, in Eclipse, triggers the “compile” step. So you really get a loop of “change” -> “change” -> “change”, with occasional interruptions due to (unexpected) test failures.
Eclipse’s compile step is extremely fast, and gives you about the same turn-around time as interpreted languages do.
The “change-compile-package-deploy-test” cycle is death – you only want to do that when you _really_ need to, which is nowhere near as often as most people think.
I avoid most of the “change-compile-package-deploy-test” pain with unit tests for the java code and working with static HTML snap-shots for pages (especially JavaScript issues). Once I reach the point where I must deploy, the grunt work is done by my build script and where appropriate, watir for exercising the page(s).
The longer the cycle time, the more it benefits you to *think* — never a bad thing. When the cycle time is too short, the temptation is to just hack it until it works — which frequently results in a “fix” that is fragile, because it addressed the symptoms and not the root cause. Your optimum cycle time is decided by, among other things, your ability to resist the “hack until it works” approach.
Aah. you missed another important step in the “Enterprise” J2EE application -> change configurations in xml.
Robert – I have used that in Eclipse before and automates a lot of the process which is nice.
John – I agree that a longer cycle time gives you more time to think which can be a good thing – but then it forces that time upon you, instead of you being able to choose (which I prefer). This is, of course, subject to abuse by code monkeys not willing to think 🙂
Suresh – I agree but had thought of this as part the “Change” phase.
Thanks all for your comments!