Birthday greeting kata in C# .Net

One of the katas that I have recently had the pleasure of finding and trying out is the birthday greeting kata by Matteo Vaccari. It's a great exercise in what I have termed "refounding" of existing software (see an earlier post). Here is an opportunity to take existing code, refactor, and add unit tests.

Now I'm no java expert and although I had fun playing around with Eclipse, I felt more like a toddler learning to take it's first steps than a kung fu code master (not that I am that either mind you). So I decided to have some fun and port the code to C# .Net. If you're interested you can find it here (Visual Studio 2008 unit testing).

Have fun :-)

Refound your software

I've experienced first hand how making any changes to existing in use software can be a nightmare. Complaints from the business that each new change seems to take longer, cost more, and lead to new bugs are well justified. Why is this? Well scrum has taught me all about technical debt, and how this leads to increasing problems as the life of the software lengthens. So obviously, next time I'll do it better!

But for now, for all those companies with existing software suffering from technical debt, what about them? Well, I like the concept of "refounding" or rennovating them. So don't throw the software away and start over. This is much to risky, costly, and time consuming. Instead, whenever a change needs to be made to the software use the following steps to refound safely:

- create tests (most likely not unit tests) for the code that will be changed and make sure that they run (green).

- refactor the code to improve the structure and allow unit test to be created (enabling mocking is an important one here). Do this is small steps and make sure that after each step all tests as still green.

- then make the desired changes that triggered all this (be it a bug fix or a new feature etc). Of course, use test driven development here, and again make sure all tests stay green during the process.

This way, the software is improved slowly step by step, but only in the areas a change was desired anyway. So the entire software is not refounded, only the parts driven by business value. Most likely, 80% of all the changes will focus on 20% of the code. So refounding is a low risk, driven by business values approach to improving existing software. I think this will go a long way to lengthening the life span of existing software.

Agile books

My first agile/scrum book was "Succeeding with agile" by Mike Cohn. At the time, I was looking for an introduction to Scrum. This book was not it. The book is all about how to introduce scrum into your organization, so it assumes you know what scrum is and preferably have had some experience with it. That being said, I learnt everything I needed to know about scrum as I read it. In addition, as a bonus, I immediately also learnt the troubles one is likely to encounter in the "real" world with scrum: organizations that say "great, but not for us" or managers that are scared for their job, etc. So in short, it actually worked out for me.

Today I received my 2nd book: "Test driven development: by example", by Kent Beck. I'm very eagre to get started as test driven development is one of the key XP elements that works so well together with scrum, but one that few organizations (I have seen) are doing.

I have also ordered the following books to complete my agile library (for now, but I'm open to other suggestions!):

Lean software development: An agile toolkit, by Mary & Tom Poppendieck

Extreme programming explained: Embrace change, by Kent Beck and Cynthia Andres

User stories applied: for agile software development, by Mike Cohn

Test driven development workshop

The company I'm currently working for is interested in starting up with Scrum but finding it difficult to make headway. As a start, they've decided to start familiarizing themselves with some of the agile and scrum elements. For example, they asked me to prepare a Test Driven Development (TDD) workshop for them so that they could gain a better understanding of what the benefits are.

Not being an experienced TDDer either, I googled the great StingCalculator Kata by Roy Osherove and prepared this. I found this to be a great kata for TDD because:
1) it allows for incremental building of tests and functionality (triangulation)
2) it quickly demonstrates the value of refactoring and reuse of code
3) you can easily hit red when going for the Obvious Implementation (fast) and so it forces you to go back to Fake It and Traingulation (slow).

I also made a short introduction to TDD and this Kata.