2 brief comments about TDD

I just found 2 cool introductory articles about test-driven. Maybe you'll be interested:

Test Driven Development part I : an Intro>

Test Driven Development part II : Code coverage

Blogging with wordpress

I know, Im writing from Blogger, but that doesn't mean I can't use Wordpress for my other sites!

Currently I moved my christian evangelism website www.evangelismobiblico.com which was using my custom hand-made PHP code to a new one using Wordpress. Its cool, very customizable and easily to extend (Yes, more customizable than Blogger, so far). I just wanna post a little bit about the tools Im using...

I have downloaded and customized the theme Im using. CSSEdit is my best friend on doing this! HTML editing is done with Taco HTML Edit (It even previews PHP code!).

Then, any image I need to create (foe example, the website banner) is done with Pixelmator (Its really the Mac OS X Image editor for the rest of us).

Then Im using the next Wordpress plugins. Search for them in Wordpress plugins directory. They are a great help, my theme is simple but I can include functions that make the site easier to manage and include custom content.

All in One SEO Pack: Cool optimization for Search engines. Must-have.
Audio player: Every post that has an mp3 get a flash player. Its really cool since the user doesnt need to download or stream the mp3 on another page for listening.
Blog Icons: Places tags that tell where the Favicon or iphone icon reside.
Contact Form 7: Super easy form maker. I just need to add a simple tag to my post or page and automatically I got a contact form! I use it for people to contact me or to email a friend.
FeedBurner FeedSmith: Redirects all of your traffic to your feedburner account. Feedburner is also a must-have.
File Icons: My mp3 and pdf links now show a little image. Since it uses CSS3, IE6 cannot render it correctly but its a nice addon for more advanced browsers (Safari, Firefox, Opera...)
Google XML Sitemaps: It automatically updates my Sitemap.xml each time there is a new post or content. I dont need to update it manually. Also it has options for notofying other search engines about content updates. If you use Google Webmasters services, this is a must-get.
New Tag Cloud: Nice tag cloud. Its better than others in that it doesnt place a tag in font size 7 and other in 44! Its nicer than the default one.
One Click Plugin Updater: A plugin for installing plugins! I dont need to FTP anymore!
pageMash: It allows me to organize the way the static pages appear on the main menu. Its visual!
Simple Yearly Archive: Its a simple list of all the posts ordered by year. I use it on a static page.
Ultimate Google Analytics: Wow, so easy to track my website using Google Analytics. I didnt need to edit any PHP file. The plugin does everything for me. Every link gets tagged and tracked automatically! Wow.

See you around!

Great quotes on agile

Jesper Rønn-Jensen has some Great Quotes For The Agile Project Wall

My 2 favorites are:

“Life is really simple, but we insist on making it complicated” - Confucius

In software development, we usually tend to try to understand and design all on advance (maybe fearing that later we, our customers and out team won't be so smart as now?) Haha, I think that the truth is that doing requirements and programming incrementally contributes to simplicity and a better continuous understanding of the business domain and our software. So, let's keep it simple and develop in small increments.

Project success is not product success - Jeff Patton, Agile Alliance

In traditional software development, our teams are used to just completing a schedule and releasing the software, but actually our focus should be on the product success, fully satisfying the customer. This is one of the reasons I like agile methods, they focus on the product adding business value continuously.

Check the other quotes and contribute if you got more!

Thinking about documentation

In working these days in a presentation I'll be doing with a peer on "Requirements in eXtreme Programming". I'm taking a course about Requirements Engineering with a strong focus in RUPs way of doing requirements, so guess it'll be important to address the topic of why XP does so little documentation.

In the Art of Agile Development, James Shore explains the 3 types of documentation:
- Work In Progress Documentation: helps you to get your job done.
- Product Documentation: documents that provide business value
- Handoff Documentation: documents for handing off the project to a new team

Requirements documents and design documents are usually just work-in-progress documentation. The real need is how can we communicate while we develop software. XP emphasizes a whole team (customer, programmer, testers) that sits together, communicates face to face and shares a common language (ubiquitous language).

I agree completely in that oral communication is much more effective than just receiving a document (use case or any other) with a task that says "Program it". What if instead of giving documents to our programmers we give them a brief statement of what need to be done and then they have the chance to get the requirements directly with the customer? That is the idea of using user stories. They are work-in-progress artifacts. They are not little requirements documents, but they replace them with a cool combination:

On Site Customer + User Stories + Common Domain Language + Iterative Development (program byte-sized requirements) + Automated Tests (unit and customer tests)

I thought that User stories were just a lazy way of not writing use cases (or SRSs) but actually they are a smart way of remembering that we need to communicate with the customer. XP practices really support each other, so I think that before saying "XP doesn't work for me cause it does so little documentation", we should take a look at how all practices fit together.

A little conclusion: XP supports written communication with other practices that are far more effective than just written documents. (check page 195 inThe Art of Agile Development).

In the next days, I'll be googling, thinking and writing about where do use cases, as a technique, fit in agile. Hope you'll come back and read my findings and opinions!

Your best friend on the Internet?

Have you noticed that you could spend all day long just reading blogs about your favorite topic? That is cool, but only before you notice that you'll want to know which are the hottest stories and you got a million hits on Google!

That's the cool thing about Social Rank. It helps you to save time by giving you the top stories about your favorite topic. For example, I found www.agiledaily.com, a Social Rank powered website, of course, about agile software development.



I'll give it a try!

Check Top Ten Reasons that Agile Produces Higher Quality

Damon Poold posted Top Ten Reasons that Agile Produces Higher Quality. In my opinion, it's worth to check it out.

TDD Doesn't Make Development Take Longer!

Hi people, tonight I'm thinking about the conception that Test Driven Development makes your project take longer. I googled this post from Jeremy Miller and found it to be based on experience and really match what i've found on my own programming experience.

Some people say that a project can take longer cause you must write and maintain more code, and each time you suggest to include more quality in your software through tests you hear the same objections... but why is that?

Well, I think that is really a natural reaction and seems logical if you haven't developed the test-driven way (red-green-refactor). Some people think they have done TDD but they have just coded automated tests, but TDD is about design and continuous design. If you design the test-first way you are going to finish your code in a faster and better way... that's just a non issue for me. Your code will do what you supposed it should do, no more, no less. Why don't you try yourself? This is a pragmatic issue, if it works why don't we apply it and enjoy the benefits?

Jeremy Miller lists where he thinks TDD cuts development time, and I concur:

- Design
- Debugging
- Fixing bugs
- Testing

Let me add a few, IMHO:

Maintainability: When you develop the TDD way, you can refactor and change your code anytime and just enjoy the simplicity of good code and your unit tests are a safety net. That resumes in few development time and make programming more fun. Also, you can focus more in adding value to the code by reducing technical debt and improving your design cause good tests are you allies.
Trust in your own code: Since the days I started thinking and with TDD I trust much more in my code and feel more proud of it. I can even invite you to take a look any time and even make changes with confidence that my tests validate yours!
Trust in others code: if you honestly did TDD and you trust me your code for working on it, I'll feel very secure that your code will be simple, understandable and open to refactorings. We work in team environments, people come and go, and our code should be always hight quality. We'll save ourselves so much pain...

BUT, (and this is a big BUT), you'll enjoy all that benefits if you're honest and mindful about TDD. Please, don't do it as just a requisite. And PLEASE! Don't say that TDD is an overhead to software development if you haven't given yourself to learning how to do it and practicing for a little while. I can assure you, you won't regret.

If you want, take a look at this Introduction to Test Driven Design (TDD). Enjoy!