I was reading today the Agile Testing Blog and in that post he states something that I think is valuable for sharing with you. Grig says: "the goal here is to replace you (the sysadmin or the developer) with a small script. That will free you up to do more fun work."

Hey, that's true. When we automate our development, integration, deployment and any other process we are creating checklists of things that otherwise a human should do. That usually is error prone and tedious.

That's what automated testing and automated integration systems are about. If you're not into them, I encourage you to give them a try, and give yourself a chance to do more fun things!

We're on a cascade testing phase!

Honestly, there's not much excitement in delivering 359,000 lines of code of your project X into the hands of a fierce team of testers... but that's exactly where my team is right now.

SD Times reports that "A survey found that developers spent more time troubleshooting application problems than programming".

Scary! Most of us plan our schedules with lots of programming tasks and underestimate time for functional testing. That survey shows that a problem found after programming has a high cost. And if that survey predicts what the testing phase for project X is gonna be so expensive, the least we can do is to something from the experience...

What can we do? I find really interesting the philosophy that inspires Lean thinking and Agile practices. Although the project X I mentioned before is not driven by an agile methodology, we started applying Test driven development and Continuous Integration practices. I have learned a lot this year applying this practices, and I hope my team too.

The winning formula is:

Design Patterns + TDD + CI = better-tested-more maintainable code.

TDD, in my opinion, leads to a simple design which does exactly what's intended and can be continuously verified.
Design Patterns help us embrace change by making code thats more cohesive and less coupled.
CI is our feedback machine.

I don't think our software is bug-free, we are just starting to mature on this practices, but I hope to report some good things a few weeks from now. Until then, I encourage you to read more about TDD, CI and design patterns. I'm sharing some great podcasts and blogs on this page, and wish to hear your suggestions and comments. Make great code!

My blogs and podcasts in Google Reader

So, a few days ago I decided to give a try to Google Reader as my feed reader for blogs and podcasts. I can go to just one place and get to know all the new posts and even search the old ones.

Not only that, I can integrate that into my blog! Check the side bar, you can now see the "My Blogs Blogroll" and "My podcasts blogroll" that list the blogs and podcasts I'm following. When I read a post and find it really interesting i can share it on google Reader and immediately it shows in 'INTERESTING POSTS FROM OTHER BLOGS" section.

IMO, Google is a good example on how you make software for adding value to you customers...

Got "The art of Agile Development"!

Recently i've been following James Shore's blog. He's an independent consultant on applying agile methods. It's been interesting to read some of his Essays too. In fact I found his site while googling for Fit and acceptance tests. He just published his new book "The art of Agile Development". It was a no-brainer to order it from Amazon and I just received it!

I'll start to read it and by just looking at the book's index, it seems really interesting. In his page, he introduces the book:

Our goal for this book was to provide a complete how-to guide and starter kit for beginning and intermediate agile practitioners. To keep the book concrete and practical, we focus on XP. If you're new to agile and are looking for a simple, direct, and comprehensive "how to" guide, I think you'll like our book.

You can also listen to a podcast with James about his book on the Agile Toolkit Podcast.

Use cases in Agile

What can you do if your organization is use-case-driven? are you out of agile because of that? I think that many people have made the wrong statement that agile (xp, scrum, etc) promotes no documentation or that "code is the documentation", and because of that agile practices are stated to be lazzy in documenting (for example, with use cases). Check out this funny Dilbert post:



So, is agile about not documenting? Nope. The principle "Eliminate waste" from Lean states "eliminate anything which does not add value to the final product". Are documents waste? It depends. Do the right amount of documents that you need for communicating with your users, developers, testers, technical writers, etc.

Are use cases waste? My guess is they aren't if they are used the right way. If you write use cases in a Cascade style, you'll produce a lot of documents at the beginning of the project. Then, you may end rewriting them later when you and your developers know better the business domain. Rework is waste. We did that in some projects this year and maybe a learned lesson is not trying to figure out everything from the beginning.

If you ask me, I may propose you to write use cases on a "Just in Time" approach. For explaining this approach I'll post about User stories and uses cases later. Meanwhile, I recommend you to read this explanation of 10 simple rules of Lean Manufacturing applied to software: http://www.agilealliance.org/system/article/file/783/file.html

Check other funny Dilberts on extreme and agile programming here: http://globalnerdy.com/2007/11/28/dilbert-on-extreme-and-agile-programming/

Make great code!

A real Continuous build server

Last week I was in a Microsoft seminar about all the new stuff in VisualStudio 2008. Something new in VSTS is Team Build 2008, the continuous build server from Microsoft. Since, I haven't found much of it in the web, I'll wait to meet someone who really uses it. Meanwhile at work, we use CruiseControl.net, its an excellent, full customizable build server, and it is Open Source. It's really cool. So, as a way to to contribute to the community, let me show you our build server implementation:

Here, you can see the web dashboard. On a single page anyone can know the state of our code base (right now, we got 500.000 lines of .Net code (not taking automated tests into account).

Every time a developer delivers some code to SourceSafe (yes, believe it or not, we still use VSS), CruiseControl compiles the project's code and runs all of our automated tests. If the code compiles and all tests pass, the build is shown in green (success!), otherwise, its a failed (red) build. Then, you can check the build's detail page. CruiseControl stores all the builds history and details. Here's how the build detail page looks like:
.

We use a full open source approach for enforcing our TDD and CI in .NET:
- NUnit: Unit testing
- Rhino Mocks: Object mocking framework for .Net. IMO, it's better than NMock2.
- NCover: Reports the code coverage of our unit and integration tests.
- SourceMonitor: Gives us code metrics. For example, # of lines of code and method complexity.
- CruiseControl.Net: Our build server.
- Nant: Scripts that CruiseControl executes on each build.

So as you can see, you can use open source tools to leverage a continuous integration strategy. I'll be glad to know if you got questions or comments!

Stay fit in Acceptance tests

Last week, I read some articles about automated acceptance testing. Since I read about JUnit for unit testing in Java (2001?), automated testing has been one of my interest areas, although I didn't use it the Test-Driven way until this year. At work, we develop on .NET and use an open-source strategy with NUnit, RhinoMocks and NCover. I'll post more on TDD and how we use it at work later. But for now, Id just say that unit testing really rocks... so, I'm curious about acceptance testing automation and how can it be integrated in a continuos build strategy.
I read here that:

"Fit.c2.com may be the next big thing
It could be even bigger than JUnit"

Could it be so cool? So Im starting to read about Fit and Fitnesses as automated acceptance testing frameworks and trying to imagine how could we maybe use Fitnesse for .NET on future projects...
Check out my related bookmarks on Delicious: http://del.icio.us/ocenteno/AcceptanceTesting

my Daily scrums insights

I'm grateful about a good week at work. Last week, we had our daily Scrum meetings, or standups as they are usually called, and I think the communication is a lot better between us. My team (Christian, Alex and Marcia) have been working for 3 months together. One of my issues I dont like of project management is that the MS Project schedule isn't enough for me to keep track of the project's progress. In my opinion, it's just too impersonal. Daily meetings as proposed by Scrum seem to me a good tool for helping the whole team to communicate. We found several requirements and schedule changes this week, but our daily meeting helped us to be always in sync. Next week, I'm not going to be at the office, and the standup meetings will be the teams way to keep on the good communication. As for our 1 week trial, I can say that they have added value to our software development efforts and we'll continue to use have these scrum meetings. Can they help you too/ Hope so!

I'll post a pic of my team on a Daily standup later!