An interesting article on DeveloperTesting.com talks about Test Driven Development (TDD), Unit Testing, and Extreme Programming (XP) at Google.
Given the large code base and the number of new projects being done at Google, they have adopted unit testing and Extreme Programming in their project development. Their development teams are self-directed, providing happier and empowered software engineers. Based on their adoption of unit testing, test driven development, continuous builds, and extreme programming, Google appears to be turning out more stable releases and having other positive metrics.
It sounds like Google is going through the same changes I have been going through as a developer during the last 6 months, but of course Google is going through it at a much larger scale. Many of my posts the past 6 months surround test driven development, unit testing, and experimenting with agile and iterative development.
I am fairly comfortable with test driven development now. It was painful at first. Not so much in writing tests, but changing the way I develop applications. It was very laborious and felt very time consuming at first, but now I rather look forward to the process as I feel empowered to actually be using a development process that simplifies my code, justifies the need of every piece of functionality, helps in layering my applications, and gives me a way to measure the health of my application and find problems when maintaining and adding new code in the future. I love it.
After reading Applying UML and Design Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development by Craig Larman, I am now using a custom version of Agile UP as presented in the book. I say “custom”, because I am still getting comfortable and knowlegable about various agile methods and trying to find what works for me. Given my love for test driven development, Extreme Programming may better suit my needs, but I will probably take what I need from several methodologies, which is okay.
Regardless, I think the key is iterative development. You want to develop your applications in short iterations ( 1 - 2 weeks for my projects ) that produce quality subsets of your application. For me, these iterations have to produce a compilable and executable subset of the application from which the client can provide feedback. I also agree with Craig Larman in that your initial iterations should focus on a combination of Risk Driven Development and Client Driven Development Requirements. Hit those requirements first that are architecturally significant and difficult as well as provide those features that are signficant to the client. If you wait on the tough stuff until the end, you are setting your project up for doom if it turns out you cannot pull off the critical functionality based on your earlier work. You risk the chance of an application core rewrite.
I can't find the post by Jim Newkirk, but Jim had mentioned at some point how he also works in intervals of 2 hours. He picks functional and non-functional requirements that he can start and complete in 2 hours. This way he doesn't have the overhead of figuring out what is unfinished during his next 2 hour session. As soon as I read his post, I started the same practice, which makes sense, but is not necessarily obvious. I have cut down on a lot of errors and head scratching as to where I left off during development by focusing on what can be completed in entirety in 2 hours. Every 2 hours it is essentially the same thing. Check out my source code. Create functionality “X” using test driven development. Check back in my source code, which kicks of a build of the application. Update my development logs of bug fixes and new enhancements. Continue. That is a shortened version, but you get the idea. Bite of your time in intervals that you can start and finish completely. This includes testing, profiling, etc. You not only complete the functionality, but it has to be of high quality. No throw away code, unless you are doing some basic prototyping that essentially occurs before development starts. Prototypes can be tossed.
I know these topics are a bit hyped, but hyped for a good reason.