Chris Gough

Chris Gough

Attendee, CITCON Asia Pacific 2007

I'm a technical manager for the Federal Government (Department of the Environment and Water Resources). I'm coming to CITCON because I am in the process of rethinking our testing strategy, and I suspect CI could be an important feature of that. My contact details are:

* phone: +61 2 6274 2011
* fax: +61 2 6274 1105 (shared, make sure it's addressed to me and has a page count)
* mobile: 0418 441 605 (use this at CITCON, of course)
* email: chris.gough@**************.gov.au (can you guess the domain?)

Background

Specifically, for the last few years I have manage support, development and maintenance of systems used (by the Approvals and Wildlife Division) to administer the Environmental Protection and Biodiversity Conservation Act of 1999 (EPBC Act). Before this gig I used to teach at the Canberra Institute of Technology (Software Development Department). Before that, I was a developer (> 10 years).

* Department of the Environment and Water Resources
* EPBC Act at The Department
* Department of Software Development, CIT

My CI story

We suffer from "packaging and deployment" bottlenecks, I figured CI would force the developers to streamline the build automation and keep it working. I also hope that it would contribute to a better culture arround configuration and change management, and of course push the automated testing front and centre. Our unit-test coverage is patchy, basically M&C layers are OK (J2EE with EJB.v3 on JBOSS, standard stuff) but V (Facelets/MyFaces with a smattering of JSP) only has token automated tests, still largely manual (expensive, slow, yuck). It feels like "I have to run hard to stay where I am" to maintaining this level of coverage at the moment, but still don't feel confident going into maintenance without the DEV team on hand.

I expect to quadruple the amount of Java code in production over the next three years. At the moment we have one non-trivial J2EE app in production/maintenance, development starting soon on another one, and another compelling business case in circulation.

What's unique about developing software for the Federal Government is the impedance mismatch between the basic assumptions of agile, iterative methodologies and the fundamentally waterfall procurement processes that, by law, we have to follow. I've come to learn more about CI and Testing, but am more likely to be able to contribute to discourse in that space if anyone's interested.