Most of us would agree that having an Automated Build is a good idea. After all, we invest a great deal of time and energy in creating, monitoring and maintaining it. Have you ever ponder why it is a good idea? Here is what I think.
Here are some common and obvious answers:
- ensure that we can produce deployable units.
- ensure that our application will run in an environment that is closer to the production environment.
- ensure that the changes that we make integrate well with others.
- deploy our code to an environment that our Customers can play with and verify our changes.
- provides a mechanism to run *all* of our executable tests automatically and regularly.
- ensure that we can deliver quality software.
I think the above reasons are good ones. However, I also feel that answers like those above is only scratching the surface of the reasons why we hold our Automated Build so dear. First, lets think about the way we work in an Agile Team and what we value.
We like building high quality software for our Customers. We understand that a good way to give our Customers exactly what they want is by building something, showing it to them, listening to their feedback and incorporating it. The shorter the build, show, listen, and incorporate cycle is, the less likely we will waste our effort (including our Customers’) in misinterpreting their requirement. In order to support this rapid cycle of delivery, we need something that can give us feedback of our work quickly. We need a reliable and repeatable way to test, build and deploy our software. And, it must be FAST!
How do we make that cycle super short? You got it. By keeping everything we do as simple as possible. As we all know, it is so much harder to simplify something that is complex to begin with. Automating something that is already complex can only multiply its complexity exponentially. Keeping things simple is key to sustaining a short build/show/listen/incorporate cycle. We need a simple way to test and package up our code for deployment.
We believe that our Customer appreciate software of high quality. After all, they had invested a lot of money in us to build it. How do we deliver software to our Customers rapidly, incrementally and of high quality? The answer is, we need to be able to evolve our designs (Emerging Design) and refactoring. However, relentless refactoring is not for the faint of hearts. It takes Courage. If we have a mechanism that can validate and give us feedback of our refactorings and changes to the system; we will have more confidence about making changes and therefore boasting our courage.
A high performance team is made up of team members with mutual respects. This applies to respect in each others code as well. We need a way to find out about the code that we write integrates well with the work contributed by our fellow teammates. We need a way to unambiguously identify of our conflicting changes to the system, so that we can resolve them amongst ourselves in a productive and respectful manner.
A very effective way to communicate with our Customers is by showing a working version of the system. It creates a shared view of our ideas. For instance, we can spend a lot of time in documentation, discussion in meetings, drawing up designs diagrams, planning what we are going to build, and etc. Or we can simply say, “let me just *show* you what I mean”. We need a way to build working system to facilitate and disambiguate our communications.
In order put the above Agile Values into practice, I believe we are going to need the help from “something” that resembles an Automate Build process. However, we must be mindful that it is not the only way but it is a very promising one. It is also a good concrete starting point. We must remember that, Automate Build is an Agile Practice that is derived from Agile Principles and Values. So, next time when we ask the question, “How is our build doing?”; we should answer it by asking ourselves, “How well does it support our Agile Values?”.